UHF radio control for submarines (openLRS, LoRa, FSK etc. on 458Mhz and 433Mhz )

Many thanks Tim.

Yes, this DIY approach is very alpha!

The DIY TX and RX stopped working shortly after the video. It is finicky and seems to have periodic problems with binding for no obvious reason. More bench testing needed.

The DIY RX used with a Hobbyking TX module is much more rugged and I would be prepared to test it in a submarine if the Covid virus would let us return to the pond at Barrow.

The main thing is that your work and observations on the use of openLRS on 400 to 500Mhz  enabled worldwide model submariners to have  more options for r/c equipment.

Mind you, in the UK, I am a bit worried that the 458 Mhz band could be sold-on. John Robinson tells me that it's main use is control of traffic lights which is preventing it being sold-off!

Keep well!

we shall all now bow down and offer our prayers for your traffic lights...  may they stay on 458mhz for perpituity... :)

Amen for all that. Long may our traffic lights flash! (I think your expression was a "first world problem!")


The photo shows the Mark 2 DIY RX ready to roll. (Long and slim with end connections fits nicely in a WTC. Needs some heat shrink.)

These are working very nicely in my Nordenfelt model sub on the bench and are ready for testing in the pond whenever the virus permits. I am using them with a Hobbyking TX module. (Still in stock, I notice.)





Much less good news with the DIY TX version. I have had them working well but only for a few minutes and hours before they cease to work. It is as if they lose "bind". Getting them to work again is a frustratingly random event with no obvious cause.

Using a TX module as a Spectrum Analyzer (Very useful!) shows no transmission. (The Hobbyking TX module shows up nicely on the analyzer.)

I don't know enough about how the hardware and software works to identify the problem. Will a module normally transmit continuously or does something in software prevent it? I don't think that the module's transmitter side has been "fried". I always have an antenna connected.

A shame that there isn't a DIY RX and TX pair yet, but overall we have made progress.

David, could your problems with the DIY TX module be the same basic problem you were having with the chinese made atmel328 boards you were using for your telemetry? try a DIY TX 2.0 made with a real "Arduino Nano Every" board and see if it fairs any better.

this just popped up on my radar:

https://www.youtube.com/watch?v=vdoVFcmHq8Q

https://github.com/AlessandroAU/ExpressLRS

https://www.rcgroups.com/forums/showthread.php?3437865-ExpressLRS-DIY-LoRa-based-race-optimized-RC-link-system


it is the newest iteration of LRS, but not the same as what David and I have been messing with. major difference is that it uses the newer 32bit microprocessors, so it has considerably more horsepower to do things faster, which is good for drones, but not so much us. however, the update rate can be altered, so perhaps the lower rates might offer more range... which is helpful to us.

Copied over from Facebook:

Jonathan Askey
David Forrest - how odd - happy to have a look and see if anything pops out of the wood work...
· Reply · Share · 6d
Jonathan Askey
David Forrest - did you get a fix? My hunch would be that you need to observe 3.3v and 5v requirements and eliminate this as a potential problem and an easy win...
I am currently attempting to use modified code to work with RFM69HCW on breakout boards as I have successfully used these for a long time and they are a solid workhorse - time is always the challenge and a DAC project is often grabbing my attention...

Thanks for the very useful TX suggestions, Guys,  (the RXs are working fine on the bench) which I have investigated as shown below:



(1) and (2) are TX breadboards  using REAL Nanos (the Nano Every doesn't work in the Configurator) to eliminate the "clone wars" (yes, one of my Nano clones lost its configuration settings in eeprom overnight!). They both have voltage level convertors for all 5 pins. (Not just for 4 as in the Mark 2.)

So this is as you both suggested.

Number (1) worked well for several days but has since stopped working. (2) has never worked.

The problem is that they don't transmit, as monitored on another module acting as  (a really useful) spectrum analyzer.) (I have confirmed that the TX module always transmits as long as it is getting a ppm stream. Another handy tip is don't tick the Bind Code box in the TX screen of the configurator. This keeps the same bind code for everything you do.)

Number (2) doesn't work even when all the chips are swapped over from (1) which suggests a wiring fault (I have checked everything) or that the physical layout is stopping it working.

Number (3) just works well all the time! It is a "Mark 2" receiver flashed with the TX software. The range isn't brilliant only about 60 metres but it only has the basic aerial.

It is all very puzzling and I am running out of theories why the TX is so much more of a problem than the RX.

The following are possible explanations:

- rf module faults, quality control?? Is running them at 458 Mhz a problem?? (I have some more on order.)

- the fact that the TX (not the RX) is the problem maybe suggests that power supply or power up could be the problem. The Si4330 datasheet on page 50 gives a rather frightening description of a "Smart Reset" triggered by all sorts of factors at switch on. I will try some on-board capacitors and separate 5v and 3.3 volt power supplies.

In summary though, it is not looking too promising for a DIY TX.  The best advice at the moment is build a handful of Mark 2 RXs in the hope that one will be able to act as a TX ! The RX is looking OK.

David

PS (1)  I am going to take a look at Tim's previous post about a peak into the future of openLRS. (It would be nice to move the technology into Lora etc but we need  lower frequencies (Less than 500Mhz. Subs have such different needs to drones.) and someone has to do the software. openLRS is nicely developed and available at no cost.)

PS (2) In answer to your question, Jonathan, I am still using the pinout connections shown in my post here  of  17 Oct 2020 - 9:55 called "New Chinese sourced module (Mark 2)" (HV, LV etc refer to the voltage level convertor module.)

David, not sure how much impact this might be having on what you are doing... as far as i know, all of the actual commercial openlrsng hardware is based on the 3.3v 8mhz atmel atmega328p chips.

Hi David,

I have made significant progress in my experiment and absorption of the openLRS libraries - still a way to go yet

I have a question regarding the practical use of binding.

If binding worked where the bind phrase was entered into hard code and downloaded to TX/RX rather than "on air" binding would this be a significant issue?

Regards
Jonathan

C-3PO wrote:Hi David,

I have made significant progress in my experiment and absorption of the openLRS libraries - still a way to go yet

I have a question regarding the practical use of binding.

If binding worked where the bind phrase was entered into hard code and downloaded to TX/RX rather than "on air" binding would this be a significant issue?

Regards
Jonathan

the "bind phrase" as you call it is a unique identifier to all transmitter modules.  if that is not allowed to be changed, that would effectively remove the bind process, and the receiver would work with the first transmitter it found broadcasting. (since all transmitters would have the same ID)

Good point about the 8Mhz 3.3v Atmel, Tim.

So I have just been trying a a Pro-Mini (3.3v and 8Mhz) but using the Configurator is the problem.

I can flash the Firmware (DTFUHF 4ch as TX) on the Configurator but I can't make a connection to load the Configuration data??

When I then press the bind button on switch on (to produce the rapid beeps) the Spectrum Analyzer shows transmission at about 435 Mhz. This looks hopeful and is presumably a default configuration for the rf chip?

This brings me on to another observation. All my nano based TXs have now stopped working - no transmission at 458Mhz showing on the Spectrum Analyzer. Try the bind button(as above) and I note transmission at about 435Mhz with both of the "failed" TXs I have tried this with.

Is the problem that the configuration data is being lost and it reverts back to default?

david f wrote:Good point about the 8Mhz 3.3v Atmel, Tim.

So I have just been trying a a Pro-Mini (3.3v and 8Mhz) but using the Configurator is the problem.

I can flash the Firmware (DTFUHF 4ch as TX) on the Configurator but I can't make a connection to load the Configuration data??

When I then press the bind button on switch on (to produce the rapid beeps) the Spectrum Analyzer shows transmission at about 435 Mhz. This looks hopeful and is presumably a default configuration for the rf chip?

This brings me on to another observation. All my nano based TXs have now stopped working - no transmission at 458Mhz showing on the Spectrum Analyzer. Try the bind button(as above) and I note transmission at about 435Mhz with both of the "failed" TXs I have tried this with.

Is the problem that the configuration data is being lost and it reverts back to default?

Hi David - the default carrier/binding frequency is 435 Mhz

See library file bindings.h code line 97

tsenecal wrote:

C-3PO wrote:Hi David,

I have made significant progress in my experiment and absorption of the openLRS libraries - still a way to go yet

I have a question regarding the practical use of binding.

If binding worked where the bind phrase was entered into hard code and downloaded to TX/RX rather than "on air" binding would this be a significant issue?

Regards
Jonathan

the "bind phrase" as you call it is a unique identifier to all transmitter modules.  if that is not allowed to be changed, that would effectively remove the bind process, and the receiver would work with the first transmitter it found broadcasting. (since all transmitters would have the same ID)

Something got lost here is translation. Tim, you speak about what I already know!!

I am not suggesting that there isn't a unique key in use that ensures only predetermined "paired" devices can exchange valid data. I was simpy proposing that the unique key was defined in software as part of the "program code" before it was downloaded to the TX/RX.

In other words you would not be using eprom to store bind data on the fly - when you press the bind button and interigate over the air the bind key. - I was questioning what fallout there would be from this approach... guess the obvious is you would not be able to "bind" at the pool side - would need to be done in advance with access to a computer.

So I have seen enough of the "under the hood" openLRS to determine that I won't use it - IMHO it is way to complex and I am not sure why! - Maybe I'll be eating my words at some point in the future

There is a far easier way to achieve much of the functionality with a very simple system (both software and hardware) I would suggest would be more robust - time will tell

Watch this space....

C-3po,

in the general gist of things, i agree with you. there is absolutely no reason i can fathom that openlrsng is as complex as it is...

my guess is that it started out simple, and each new maintainer added his or her own tweaks to it until it became an un-maintaneable mess.

i have had many a thought on making my own modules and receivers using much simpler code, but just don't have the time to debug any hardware issues that may crop up. it was much simpler to just buy off the shelf hardware and deal with minor inconveniences.

as to the binding... the need for a pc is the exact opposite of anything i would use. if it can't be done with just the transmitter, it is too complex.

david f wrote:Good point about the 8Mhz 3.3v Atmel, Tim.

So I have just been trying a a Pro-Mini (3.3v and 8Mhz) but using the Configurator is the problem.

I can flash the Firmware (DTFUHF 4ch as TX) on the Configurator but I can't make a connection to load the Configuration data??

When I then press the bind button on switch on (to produce the rapid beeps) the Spectrum Analyzer shows transmission at about 435 Mhz. This looks hopeful and is presumably a default configuration for the rf chip?

This brings me on to another observation. All my nano based TXs have now stopped working - no transmission at 458Mhz showing on the Spectrum Analyzer. Try the bind button(as above) and I note transmission at about 435Mhz with both of the "failed" TXs I have tried this with.

Is the problem that the configuration data is being lost and it reverts back to default?

David, are you certain you are choosing the right hardware type for the firmware you are downloading?

tsenecal wrote:

david f wrote:Good point about the 8Mhz 3.3v Atmel, Tim.

So I have just been trying a a Pro-Mini (3.3v and 8Mhz) but using the Configurator is the problem.

I can flash the Firmware (DTFUHF 4ch as TX) on the Configurator but I can't make a connection to load the Configuration data??

When I then press the bind button on switch on (to produce the rapid beeps) the Spectrum Analyzer shows transmission at about 435 Mhz. This looks hopeful and is presumably a default configuration for the rf chip?

This brings me on to another observation. All my nano based TXs have now stopped working - no transmission at 458Mhz showing on the Spectrum Analyzer. Try the bind button(as above) and I note transmission at about 435Mhz with both of the "failed" TXs I have tried this with.

Is the problem that the configuration data is being lost and it reverts back to default?

David, are you certain you are choosing the right hardware type for the firmware you are downloading?

Orange TX uses AT Mega328P AU1200 / RX uses AT Mega328P AU1340 - aren't these 20Mhz 1.8 to 5.5V chips?

from the spec sheet:

Speed Grade:
– ATmega328/P: 0 - 4 MHz @ 1.8 - 5.5V, 0 - 10 MHz @ 2.7 - 5.5V, 0 - 20 MHz @ 4.5 - 5.5V

i believe they are running everything at 3.3v, to remove the need for logic shifters etc.

so, at 3.3v, best possible speed would be 10mhz - and they are running them at 8mhz to keep things stable

Thanks both!

Thinking back to the original intent of this project, it was to see how far we could go with existing hardware and software to make a DIY RX. I think that has been successful. I will be happy to try the DIY RXs in a sub when the pandemic gives me a chance! The DIY TX was going to be a luxury and I think we are fairly close anyway. I see that the Hobbyking TX modules are still available anyway for the princely sum of £4.05. For anyone interested, buy one if you haven't already! (It should be possible to use it as an RX also.)
https://hobbyking.com/en_us/orangerx-open-lrs-433mhz-transmitter-100mw-compatible-with-futaba-radio.html?queryID=8378838a9fb113106afe2355829edc9e&objectID=46638&indexName=hbk_live_magento_en_us_products

Tim has opened up a new frequency range and technology for model submariners with some significant advantages including telemetry and the ability to get rid of crystals and wooden frequency peg boards!

Over to Jonathan and C-3PO for the use of new hardware and simpler software. (Which WILL need a really simple way of inputting a bind code.) Keep us in touch!

Regarding the DIY TX. I have been trying the Pro-mini at 3.3 v volts and 8 Mhz. I still can't get the Configurator to connect so that I can set the TX configuration.

A good question,Tim, about using the software that matches the hardware. I am not 100% sure to be honest! I can flash the hardware using the configurator for both the Pro-mini and the Nano (With the exception of the Deluxe hardware. I think they use different processors.) Then trying to connect to set the configuration works for some hardware options but some of these don't give the spectrum analyzer option. (A useful test) The DTFUHF 4ch as TX seems like the best option.

My overall conclusion about the TX trials is that it is very strange that they nearly all worked well for several days before failing one by one. To me, this points towards hardware failure and I have some new rf chips on order to test this out.

I have been jogging through the original source (2014!) for a lot of these ideas on r/c groups:

https://www.rcgroups.com/forums/showthread.php?2114859-Cheap-Easy-DIY-openLRS-openLRSng-RX-TX-modules

It is difficult to follow because everyone seemed to develop their own hardware route but I don't see any details of a working DIY TX. Could this be a lesson for us?

tsenecal wrote:from the spec sheet:

Speed Grade:
– ATmega328/P: 0 - 4 MHz @ 1.8 - 5.5V, 0 - 10 MHz @ 2.7 - 5.5V, 0 - 20 MHz @ 4.5 - 5.5V

i believe they are running everything at 3.3v, to remove the need for logic shifters etc.

so, at 3.3v, best possible speed would be 10mhz - and they are running them at 8mhz to keep things stable

Hi Tim - thank you for correcting my oversight - Doh! - I realised this after I posted as you state they are running on 3.3v

Regards
Jonathan

david f wrote:Thanks both!

Thinking back to the original intent of this project, it was to see how far we could go with existing hardware and software to make a DIY RX. I think that has been successful. I will be happy to try the DIY RXs in a sub when the pandemic gives me a chance! The DIY TX was going to be a luxury and I think we are fairly close anyway. I see that the Hobbyking TX modules are still available anyway for the princely sum of £4.05. For anyone interested, buy one if you haven't already! (It should be possible to use it as an RX also.)
https://hobbyking.com/en_us/orangerx-open-lrs-433mhz-transmitter-100mw-compatible-with-futaba-radio.html?queryID=8378838a9fb113106afe2355829edc9e&objectID=46638&indexName=hbk_live_magento_en_us_products

Tim has opened up a new frequency range and technology for model submariners with some significant advantages including telemetry and the ability to get rid of crystals and wooden frequency peg boards!

Over to Jonathan and C-3PO for the use of new hardware and simpler software. (Which WILL need a really simple way of inputting a bind code.) Keep us in touch!

Regarding the DIY TX. I have been trying the Pro-mini at 3.3 v volts and 8 Mhz. I still can't get the Configurator to connect so that I can set the TX configuration.

A good question,Tim, about using the software that matches the hardware. I am not 100% sure to be honest! I can flash the hardware using the configurator for both the Pro-mini and the Nano (With the exception of the Deluxe hardware. I think they use different processors.) Then trying to connect to set the configuration works for some hardware options but some of these don't give the spectrum analyzer option. (A useful test) The DTFUHF 4ch as TX seems like the best option.

My overall conclusion about the TX trials is that it is very strange that they nearly all worked well for several days before failing one by one. To me, this points towards hardware failure and I have some new rf chips on order to test this out.

I have been jogging through the original source (2014!) for a lot of these ideas on r/c groups:

https://www.rcgroups.com/forums/showthread.php?2114859-Cheap-Easy-DIY-openLRS-openLRSng-RX-TX-modules

It is difficult to follow because everyone seemed to develop their own hardware route but I don't see any details of a working DIY TX. Could this be a lesson for us?

I got stuck last night with my pet hate - conflicting interuppts which just requires a simple rewrite - I ran out of time or I would have something to show.

The concept of reading the ppm stream for the TX handheld, stuffing the content into a data packet and getting it to arrive intact (encrypted) remotely is incredibly simple and involves very little code. Sending back telemetry data is equally simple.

It would be neat to think about the core required functionality to carry across from openLRS - the basics involve 2 libraries and a few 10's of lines of code once variables and packet structure are declared

Posted this video before - you are seeing individual data packets being transmitted and received

https://www.youtube.com/watch?v=Tvze6oTdtaI&feature=youtu.be

Regards
Jonathan

I am VERY PLEASED to say that the DIY TXs are working again!

I will take you through the story.

This morning I received the 3.3 voltage regulator (1 amp output) in the post  so that I could try separate 3.3 and 5v supplies.

I connected these up to the module and fed it with a ppm stream from a Futaba 9C Transmitter from the Trainer plug.

I had also read on:

https://www.rcgroups.com/forums/showthread.php?2114859-Cheap-Easy-DIY-openLRS-openLRSng-RX-TX-modules/page26

Reply no. 384.

That you should do bench testing  with the TX set to low power for bench testing. I reduced it from 7 to 2. (For Spinal Tap fans, 11 isn't available!)


EVERYTHING WORKED!

Back tracking on what I had done, I found that the separate 3.3 supply was not necessary. The secret was the low power setting. (I found that the separate 5v supply to the Arduino was necessary. Don't trust the voltage regulator on Vin to give 5v from the Transmitter battery.)

I don't know why this works! Does the rf module stop transmitting if the RX is getting excessive signal strength?

Anyway I will let you know if they stop working over the next few days - as happened in the earlier tests

glad to hear that you are slowly working through all the issues that have come up... i had heard similar things, especially during the bind process.

https://electronics.stackexchange.com/questions/455233/what-does-it-mean-to-swamp-a-radio-signal

David,

Are you using telemetry with your "homebrew" kit?

Regards
Jonathan

Tim,

Finding that the power setting needed reducing for bench testing was a game changer. All the DIY TXs now work reliably with all the RXs (Admittedly still on the bench and not underwater!)

I now realise that some of the glitchy problems I had were also being caused by "swamping" - the servos would not respond proportionately but were switching through 90 degrees.

Jonathan,

Yes, it does work with telemetry. The photo shows my breadboard combined TX or RX, plugged into my transmitter training port and with an Arduino Every and an oLED display. It is reading 10 volts on the submarine lead acid battery. The software for the telemetry sender and receiver are on my GitHub site. It is basic and just sends battery volts and amps drawn. (https://github.com/rdforrest/openLRS)



I think that is about it for the homebrew version using existing software and hardware. Over to you for some "pretty amazing new stuff!"

Hi David,

You must be pleased that you have been able to identify the physical issue (receiver overload) and now have a working solution.

My approach to reinventing the wheel is 100% (KISS) so others would be able to easily pick up the code and take it in any direction they so please.

Right now I am indulging myself with some audible feedback scenarios - not just loss of signal/packets but "no ppm / low signal" etc but the tone command is code blocking so considering an attached Attiny 85 to take care of the audio, or perhaps see if it's possibel to serially command the handset audio

I will then see if I can understand how the telemetry works - I presume the module in handset sends data to handset serially?

On the to do list is channel hopping and binding - any other pointers as to worthwhile functionaility?

Regards
Jonathan