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

Another test of the LoRa system in my Turkish Nordenfelt model. I am quite happy with the system now and I will use it as my control system "of choice" from now on. (With openLRS used occasionally.)

It has quite high latency but this is OK for submarine models, I think. I like the telemetry (battery voltage is so useful if you are using Lipos) and the failsafes (set in software.) The range (including submerged) is very adequate.

The latest version of the software continues to send telemetry every 10 seconds even if the TX is off. This does perhaps enable lost model direction finding and location (in addition to ultrasonic Pinger use) with my foldable Yagi antenna used some months ago:



The software (Current versions LoRa-Rhead-RX-3.4  & Lora-Rhead-TX-2.7) is here:

https://github.com/rdforrest/LoRa-TX-RX-Test-458MHz








Dived with just the funnel showing!



Dived with just the funnel showing! (Typically murky water)



The TX setup installed in a (fairly roomy) 3D printed box:
The oLED display cycles through the three telemetry values. (This shows the RSSI)



This shows battery voltage:






Two TX/RX sets of equipment (fairly easy to assemble by the informed DIY builder) They all use the Adafruit RFM96W breakout board which is easier to connect to than a bare chip and has level convertors for the 5v used in the Arduino Nano:



Perhaps not the most exciting set of videos but they show the range you can expect together with demonstrations of diving etc.

https://youtu.be/1oW9hinyQcs

https://youtu.be/EuwLlZFAwpA

https://youtu.be/5Jb61F0cMoo

https://youtu.be/q9l2JEAQ9Qo

https://youtu.be/XgTsew0UZwo

So, my update on the ImmersionRC ezuhf equipment...

not worth the bother for me.

I spent the weekend of septermber 4th & 5th 1250 miles from home at a Mare Island Fun Run in "lovely" San Francisco. I took 3 submarines with me, my trusty Norbert Bruggen Delta, a Small World Models 1/96 scale Blueback (1970s era US diesel sub) and a 1/32 scale 1903 Holland. the holland and blueback were using the FrSky 915mhz equipment, and the delta was using the ezuhf equipment.

all three ran equally well in identical conditions.


One thing that was very interesting to me.

One of the local Mare Island club members was using a FrSky qX7 transmitter with a 75mhz futaba module.

https://store.flytron.com/products/turnigy-x9-futaba-module-adapter-v3

he simply wired up an old 75mhz antenna to the appropriate pin on the module, plugged the module into the adapter, plugged the adapter into the socket on the back of the transmitter, and made a bracket to mount the antenna on the transmitter, he set the protocol for the module to PPM, and everything ran as expected.

Very interesting observation Tim.

Does that mean that the Futaba modules use a standard PPM signal as input?

In which case anyone with  a 75mHz or 40 Mhz* module could plug it into the trainer plug of any TX?

Could be very useful for a lot of folks.

David

* for the UK. When last I looked they were expensive and hard to find.

david f wrote:Very interesting observation Tim.

Does that mean that the Futaba modules use a standard PPM signal as input?

In which case anyone with  a 75mHz or 40 Mhz* module could plug it into the trainer plug of any TX?

Could be very useful for a lot of folks.

David

* for the UK. When last I looked they were expensive and hard to find.

David, yes, the protocol selected when using the 75mhz (or 40mhz) modules would be ppm...  and the use of a trainer port instead might add additional "needs"  (some trainer ports invert the signal, and some require the use of a "trainer switch" to indicate who has control of the rf deck, student or instructor)...

and yes, here in the states, the 75mhz modules are impossible to find, and expensive...  but for someone that already has a drawer full of them...

I joined this forum after reading about your issues using openlrs. im probably one of the handful of people that originally used openlrs on 458mhz. Openlrs has potential for very long range and signal penetration but it has to be configured for it, the main issues i could see you having is

1. antennas, the stock openlrs antennas are rubbish and are only useful for indoor testing. make a 1/4 wave dipole using some wire or coax. you need one for both the transmitter and receiver. 433mhz antennas wont be correctly tuned, so you need an antenna that is slightly shorter to compensate for the higher frequency.

2. Air data rate, openlrs has 2 data rates in the settings, one is for the serial port and one is for the transmission rate. out the box this is set quite high as its also used for a telemetry link but since your not using a flight control system you dont need the bandwidth or the low latency so you should drop the transmission rate down to 9600 or 4800 and also reduce the number of channels to 4+4 (4 high resolution channels + 4 low resolution channels) to minimize data usage minimizing the latency. by reducing the transmission rate you more than double the range and it shouldn't effect your FRSKY D based telemetry since it doesn't use much data.

you should also look at the Beacon function of the openlrs recevier, basically if it doesn't receive a packet from the handset it will start transmitting a tone on fixed frequency lowering the power level with each pulse so you can use the RF signal to tell if your getting closer or not. this was tested to 100+ miles in open air using a baufang radio, but it should still work to a decent depth, as the signal required is much weaker than needed for a data link.


openlrs has something called channel relay mode so you can use the servo pins to directly turn signals off and on, so you can just use a opto-isolated relay to run systems.

Gents,

I have been aware of another manufacturer of the UHF equipment for quite some time, but until recently, their equipment has been too expensive for my tastes.

well, they now have a v2 set of hardware, which is now priced within my budget, so i have ordered a set.  it is the classic TX module built to fit into the JR style socket (found on many transmitters, such as FrSky and FlySky).  the set has arrived, and as before, i will be putting them into my tried and true Delta to see how well they work.

these new items are not 433/458 mhz,  they are 915mhz (USA) or 868mhz (EU)

see links for what i purchased.


tx module:
https://www.team-blacksheep.com/products/prod:crossfire_micro_tx


rx and pwm adapter (allows the drone-esque receiver to use standard servos)
https://www.team-blacksheep.com/products/prod:xf_nano_div_rx
https://www.team-blacksheep.com/products/prod:nano_divrx_adptr


as i stated, i have already received these three items, and have wired them up (soldered servo adapter to receiver) tested them, and now get to install them in a sub for testing.

the adapter gives the receiver the ability to work with 8 standard size servos, and the system also returns telemetry data, and since the receiver is a "diversity" receiver (two rf decks)  i actually get two separate RSSI signals plus receiver battery voltage as a minimal set of data.  I am also looking into seeing what other telemetry data can be collected, i will let you all know what i find as i progress.

tsenecal wrote:Gents,

I have been aware of another manufacturer of the UHF equipment for quite some time, but until recently, their equipment has been too expensive for my tastes.

well, they now have a v2 set of hardware, which is now priced within my budget, so i have ordered a set.  it is the classic TX module built to fit into the JR style socket (found on many transmitters, such as FrSky and FlySky).  the set has arrived, and as before, i will be putting them into my tried and true Delta to see how well they work.

these new items are not 433/458 mhz,  they are 915mhz (USA) or 868mhz (EU)

see links for what i purchased.


tx module:
https://www.team-blacksheep.com/products/prod:crossfire_micro_tx


rx and pwm adapter (allows the drone-esque receiver to use standard servos)
https://www.team-blacksheep.com/products/prod:xf_nano_div_rx
https://www.team-blacksheep.com/products/prod:nano_divrx_adptr


as i stated, i have already received these three items, and have wired them up (soldered servo adapter to receiver) tested them, and now get to install them in a sub for testing.

the adapter gives the receiver the ability to work with 8 standard size servos, and the system also returns telemetry data, and since the receiver is a "diversity" receiver (two rf decks)  i actually get two separate RSSI signals plus receiver battery voltage as a minimal set of data.  I am also looking into seeing what other telemetry data can be collected, i will let you all know what i find as i progress.

TBS crossfire has been around for a while but your going to run into issues if you want to use it legally, specifically 868mhz is not recognized by ofcom as being allowed for RC model control, it can be used for telemetry if the maximum transmitter power is only 10mw, thats 1/10th of the power allowed on 2.4ghz  given that the frequency is only 3x lower your going to end up with about the same range or slightly less than a regular 2.4ghz system. with 458mhz its 5x lower than 2.4ghz at the same power level of 100mw giving you the extra range and penetration. the uk has different radio laws from the rest of the eu, that's why its technically legal everywhere else apart from in the uk lol.

Realistically it doesn't matter, no one cares how much power you put out, it won't effect anything. its just something I had to look a lot into as I used to design commercial drone aircraft so everything had to be totally legal to go past the CAA. it had to have RF test certificates to show it was compliant.


https://www.ofcom.org.uk/__data/assets/pdf_file/0028/84970/ir-2030.pdf

Just a reminder that Tim is in the USA and I think you must be in the UK?
David

david f wrote:Just a reminder that Tim is in the USA and I think you must be in the UK?
David

yes my mistake.

GeoFrancis,

no worries, i am in the USA, and hopefully, this forum has an international audience, so both your info and my info is useful.

tsenecal wrote:GeoFrancis,

no worries, i am in the USA, and hopefully, this forum has an international audience, so both your info and my info is useful.

The TBS module can put out 2W when powered by an external power source, so that is a lot of power at a relatively low frequency. It's got half the penetration of 433/458 but with that much power it doesn't really matter, I suspect you will be able to go as deep as you want.

other issues you could run into are:

dynamic transmitter power is determined by the receiver RSSI sent back, the problem is the receiver is only sending back at 100mw so as soon as it looses telemetry it goes to max power. so it works dynamically up to around 100mw then just goes to full power. I found it was a bit overly sensitive, and would max power with the slightest thing so your probably better just setting it to something like 500mw and leaving it there.

2W of rf power tends to cause problems for other devices, jamming other receivers in close proximity FPV video receivers and GPS are the most effected but its usually only within 5m or so.

Line-up at the lake in Barrow this Sunday.
David Jacques newly finished DEEP DIVE VII sailing and diving well on its first outing.
Interesting that this model and the Charlie class are both operating on 458 MHz openLRS (for the Deep Dive) and LoRa (For the Charlie Class) - both without any interference problems,

An update on LoRa use in a Holland. (Barrow this Sunday)

A dive cycle. Don't try this with 2.4GHz !

LoRa on 458MHz is now my "goto" radio system.

Yes there is a sub here!

Hi David,

What bandwidth are you currently using?

Regards
Jonathan

Some interesting info in this doc - not sure what OFCOM would say...

https://lora-alliance.org/wp-content/uploads/2020/11/RP_2-1.0.2.pdf

Hi Jonathan,

The current settings for the TX software are the defaults (apart from frequency).
I quote from version 2.8 of the software:

" Serial.print("Set Freq to: "); Serial.println(RF95_FREQ);

 // Defaults after init are 434.0MHz, 13dBm, Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on

 // The default transmitter power is 13dBm, using PA_BOOST.
 // If you are using RFM95/96/97/98 modules which uses the PA_BOOST transmitter pin, then
 // you can set transmitter powers from 5 to 23 dBm:
 rf95.setTxPower(23, false); "

So the bandwidth is 125kHz. These are all just early trial settings. Nothing has been optimised for range etc. The TX is set to switch off after the data is sent only once every second but this is still acceptable for marine model control, in my view.

Interesting document, thanks. I will come back when I have had a browse through 95 pages!

David

PS An interesting point coming up from chatting at Papplewick  was that if only the BFMA and Ofcom would allow the use of 35MHz for subs, a lot of our current difficulties would be resolved. Because:

- We know that 35 Mhz works fine for subs.
- Lots of good quality 35 MHz gear in model flyers garages unused or languishing on eBay.
- 35MHz gear could even be easily modified by "certified" experts to run on 40MHz

Food for thought!

as a comparison the parameters I use with LoRa are:
frequency: 458MHz r/c band
bandwidth: 62.5kHz (approx 3 r/c channel)
control to boat: 8 bytes per message
boat to control: 2 bytes (ack and minimal alarms)
loop time: 155 msec approx for control message & ack response, so about 5 updates per sec.

the range seems OK, some 100m or so with Rx about 1m under water, but no complete sub to prove it yet!

I never got LoRa to work with a lower bandwidth, nor could I get FSK mode to work, hence the settings I use.

Can't remember how many additional bits are used as pre-amble, CRC, etc. but it also uses the address field that could be used to indenify each boat (rx).

I had a quick look at the LoRa spec, but like most specs its a bit dense! however it occured to me that if LoRaWAN takes off we could use that as it would be just like using an internet connected thing with a control app. Radio link then becomes someone elses problem, we simply use the WAN just like the www.

I dont think there is anything to prevent control of a sub remotely via the www, using LoRaWAN would be the same. I would guess for public events there might have to be a risk analysis of what happens if the link fails (boat stops).
It might be worth looking at if there is any open source code for LoRaWAN rather than just radio control (the 'software stack' using internet WAN/LAN terminology), sort of module that could be added to any white goods or similar type product, though size would probably still be an issue.
I know there are ethernet or USB modules that provide similar fuctionality - basically RS232/serial at one end to connect to user equipment with RJ45 (ethernet) or USB at the other and about 20mm x 20mm (I use them at work) but I don't know of any LoRaWAN equivalents.

just my 2 cents:  based on the limited reading i have done, the limitations baked into LoRaWan make it basically worthless for an r/c connection.  stick with plain old LoRa.  LoRaWan seems to be a poor man's wifi for tiny amounts of data for IOT sensors, (ten connections a DAY, 31 bytes per connection.) and of course the limits and frequencies are different from country to country as well.

So we may need to use LoRa "full- strength" rather than LoRaWAN "lite"?!

I have just been going through the document you suggested, Jonathan:

https://lora-alliance.org/wp-content/uploads/2020/11/RP_2-1.0.2.pdf

I'm rather confused. Does this only refer to LoRaWAN? Does this explain why there is also no mention of the UK "General model control" channels (458.500 - 459.500 MHz) in the document.

David

As I understand it the LoRaWAN is an overlay ontop of LoRa.

LoRa is the (proprietary) RF protocol, with the chirp, checksums etc. that can be used on any frequency, often referred to as the physical transport layer. This is what we could use in the 458MHz r/c band as we would be adhering to the requirements for use of the r/c band

LoRaWAN is a defined set of characteristics that if adhered to, any manufacture of euqipment will work with any other manufacturer, possibly as long as the settings are compatible. As such it is only licensed for certain bands in different contries. In the UK this seems to be the 433MHz ISM band. This effectively defines a sub-set of LoRa characteristics and restrictions, and defines a set of behaviours above the basic LoRa. Examples of this 'higher level' functionality would be some protocol for gaining access to the RF transport, and probably some additional parameters/addresses that would be included in each data packet. It probably also defines a set of message to which any unit must reposnd in a defined way, such as status/error reports, restarts. I noticed that there are various scenarios defined about how such a LoRaWAN node might opperate; send data any time, wait for a data request from the 'master' etc.

As part of the certification of any unit (I assume to be able to stick on the LoRaWAN sticker) it would have to meet their tests for such things as Tx time, Tx power etc. This is similar to buying a gigabit ethernet hub/router, they all meet the same spec and interwork, but the user has no control over the physical characteristics of the signal actually on the wire, to us its just a transport method for data we simply push in.

I had a quick look, there are some units but they seem to be the 868MHz band not 433MHz, and the only 433 module looks as if there would be a lot of dev to make it compliant (to LoRaWAN), though claims up to 300kbps

see https://www.thethingsnetwork.org/marketplace/product/ek-s78sxb-evaluation-board

not that helpfull though.

Happy to be proven wrong - I have no evidence to back this up apart from you can't find much, if anything on the Web re UK 433/458Mhz LORA

OFCOM do not mention it in any of their band plan details that I can find

I do not think 433/458Mhz LORA is allowed in the UK.

Have a look at RF Solutions - a seller aimed more at the commerical market rather than the hobbyist - they have lots & lots of boards but NO 433/458Mhz LORA

https://www.rfsolutions.co.uk/radio-modules-c10

I also think that Duty Cycle will be a big issue with Legal Lora (sounds like the name of a song) - some docs quote <1%

I  have some ZigBee transceivers - unknown to me at time of purchase the very, very low DutyCycle limit is burnt into the firmware - spend ages wondering why they worked, didn't work, they worked, they didn't work :)

Regards
Jonathan

I take your point.

I don't think it is of any huge significance but I have just bought two 433 MHz LoRa modules from PiHut, a UK supplier:

https://thepihut.com/products/adafruit-rfm96w-lora-radio-transceiver-breakout-433-mhz

Mind you they are now sold out!

David

david f wrote:I take your point.

I don't think it is of any huge significance but I have just bought two 433 MHz LoRa modules from PiHut, a UK supplier:

https://thepihut.com/products/adafruit-rfm96w-lora-radio-transceiver-breakout-433-mhz

Mind you they are now sold out!

David

Showing back in stock if anyone wants any.

An Autumn task. Just making another couple of LoRa receivers for my own use. (I had popped one by applying 12 v in the wrong place!)





They are working out OK. I still use openLRS on the faster model subs. Control response on the LoRa Rx is a quite slow.

Software here:

https://github.com/rdforrest/LoRa-TX-RX-Test-458MHz