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

I must admit the use of a commercial Tx does make for a far better looking kit, mine will probably be built in a cardboard shoebox!
In the end I decided to go with the PCA9685 16 channel PWM module in the Rx as simpler than having to convert to S-bus. The main issue as already noted by others is the frequency accuracy. However since there are spare outputs (even when using the outputs as ON/OFF) I set a calibrate output to 50% sqaurewave, fed that back to the Arduino and measured the actual frequency. This was then use to correct that nominal 50Hz set via the I2C bus. Seems to work, and has a trap if the measured frequency is too far away from 50Hz.
I still had to caibrate each servo, the two G9 used as test seem to go from 0.58mSec to 2.5mSec @ 50Hz, but these values are added as data definitions, and used to map the message values 0 to 255 to these time values.
I am finding that 3x AA bateries are not enough to power even these 2 servos when lots of test waggling is tried the voltage drops and resets the Arduino.

I've also added a small rotary DIP switch to define the RF channel; with a hex switch (0 to F) I map to channels 3, 5, 7, ... 33 so I keep away from the band edges as I think it uses about 3 RF channels due to still using LoRa. Interstingly when set to 'adjacent' numbers (e.g. RF channels 3 & 5) there is nothing received at the Rx unit, but it would be more interesting to have 2 pairs and the same test.

Using the ADC module and the resitive joysticks and a message format of 8 bits per servo seems to result in a stable servo postion, though only 256 positions spread over the 180deg travel. There is the occasional 'ZZZ' from the servos and a barely perceptible mechanical twitch but I'm not sure if thats noise pick up at the analogue joystick inputs (no filtering at the moment, but I am going from 12-bit to 8-bit so that shouldn't be a problem) or just the servo dreamingi in its sleep or a function of the PWM module. Don't think its message corruption or the CRC would flag an error.

I havent done any range checks, too cold out, and I'm building a module based in the MCP23017 16 bit I/O expander to provide the digital channel inputs. It will also I hope provide a digital trim function as another advantage of using the commercial Tx is the mechanical trim available on the joystick controls. I intend to use a digital input to increment/decrement from the joystick value as a digital trim.
I've also got a small I2C OLED display for displaying the RSSI signal strength, SNR and other lovely data from the RF module as well as the returned Rx status but thats a bit further away, but would be useful for range tests.

When I get round to it I'll put my code on github for interest.

Hi Simon,

Nothing wrong with a shoebox!  (It just seemed to me that shelling out £30 for a secondhand 35Mhz TX was worth it.)

I like the way that we are tackling this project from different angles, anyway. (Clever use of a DIP switch for channel setting, by the way.)

I think that you will find that servos are designed to be pretty tolerant to the frequency or pulse interval but you will need a better power source. Servos take a lot of instantaneous current. You will need a set of rechargeable batteries or  an analogue voltage regulator fed from a main drive battery. (Switch mode supplies can give interference problems)

I have just uploaded my version of the TX/RX software for the RFM69 RF chip to my Github.

So that means that I have the following "fairly " practical RF hardware ready for testing in a sub (and it can't be too many weeks away - lock down permitting!) :

- RFM22 based DIY RX and TX for openLRS on 458MHz.
- RFM96W based LoRa module on 458MHz.
- RFM69HCW based FSK  module on 458MHz.

I don't know which one will win out. I think that the last 2 will push forwards the use of 458MHz for subs on technically. They all have good range (100m) in air and we know that 458Mhz is OK for underwater communication  with model subs.

The problem is likely to be bandwidth restrictions (as originally pointed out by Jonathan), particularly for several users in one place. You know more about this so perhaps you can advise on this topic and my radio settings?

And yes, please share your code - it pushes this project along much quicker. And many thanks to all the other contributors!

David

Thanks for comments by the way. I've resisted getting a battery pack etc for the Slave as I am not quite sure what I aim to use in the boat, together with a motor ESC that should provide the 5V/6V receiver power from the 12V battery. I think I will go with the newer electronic motors rather than the older DC spark generators.
whilst off subject I've seen a few pictures where the battery just seems to have rubber sealant on the terminals, but then not bother to fit in the WTC, does that work?

I've uploaded my code to github now, see
https://github.com/SHopper-prog/LoRaRadioControl

Todays updates are
1. adding a 128x32 OLED (based on SSD1306) display to both Master & Slave, and scrolls through various parameters (RF channel, RSSI, SNR, freq errror etc.). Note that the adafruit library for these devices is huge, I had to find a much lighter-weight library that only does characters for it to fit in the memory. I'll probably keep the dislpay on the Slave, but get a bigger 128x128 for the Master. Library was by Bill Greiman by the way.

2. Built hardware to have the MCP23017 IO expander & ADC module. This provides 16 digital inputs, 8 for the digital channels, but the others for such things as I have a digital 'trim' on analogue channel 0 (probably the rudder). The current h/ware has 2 centre-off switches controlling 4 digital channels as both switches have 3 positions, up,off,down. The PWM chip can drive 25mA so can drive an LED directly, but I envisage controlling 12V relay boards to control pumps etc. 2 channels from a contre-off switch using 2 x change-over relay contacts would give forward-off-reverse control for a pump.

3. I've reduced the implemented channels to 4 x servo, though the s/ware is provisioned for 6. I use channel 7 as the calibration for the PWM controller frequency.

4. Receiver(Slave) errors are passed back to the Master via the ACK message and can be cleared with digital channel 7 (i.e. connect wire to GND for channel 7!).

5. Modify the Slave so that 6 consecutive Rx timeouts are needed to invoke the 'failsafe' settings. Curently these are hard-coded, I have yet to implement the expanded message set to pass the failsafe settings from the Master but thats the aim.

It seems to work OK, but I am getting the occasional Rx timeout at the Master, no errors detected at the Slave, so I'm not sure what that is at the moment, but it always recovers, so more work required, it never ends! One option if required would be to convert 2 digital channels to define 2, 3 or 4 positions of a servo.

I think my next aim is to implement the rats nest of the arduino, RF module, hex rotary switch, 16-bit input &  ADC module on one PCB, possibly with the ability to saw off the ADC & digial input if not wanted (eg. as a reduced size for the Slave), and also a box for the Master to mount the various switches & joysticks, then on the actual boat......

Thank you very much for posting your code. i have been poring over it this morning and learning a lot.

I am very impressed by your use of ACK. Jonathan pointed out that is a simple way to get data (i.e telemetry) back to the TX (Master). And we don't need much telemetry for subs. RSSI, battery voltage + one or two others.

If you could throw any light on the use of ACK? (Maybe Jonathan too if he is looking in on this) I have these threads for info:
https://lowpowerlab.com/forum/moteino/how-to-enforce-and-read-ack/
https://lowpowerlab.com/forum/moteino/sending-data-back-with-ack/

Personally speaking, I wouldn't worry about putting displays on the RX (slave). If you are fitting it into a sub you need to make everything as small as possible. Get any data back by telemetry.

Also thinking about hardware. The Adafruit LoRa and FSK modules are interchangeable so I have arranged to plug in the modules together with a pre-programmed Nano so I could change these at the pondside for trials when eventually the virus permits! I wonder why you have been unable to get the FSK version to work? Again if I was you, I would try uploading the simple RF69  examples from the RadioLib to start with and add code from there.

An interesting question about batteries. Sealed lead acid batteries are often kept "in the wet" on subs without any problems. Even 12 v ones with bare connectors just give a little green corrosion  on the +ve lead in fresh water. Lipos & Nimh are more problematic. I always keep them dry inside the WTC but I do know that  a few (brave?)  souls put them in the wet perhaps with some silicone sealant on. I would worry about water leaking between the cells on Nimh but Lipos are more in pouches so could be better? (Remember that Lipos are killed by excessive discharge so that is another good reason to have telemetry.)
This thread suggest that Lipos should be OK in the wet:
https://www.theassociationofmodelsubmariners.com/t591-li-po-batteries?highlight=Lipo
Thinking more about this, I think I would be happy to put Lipos in the wet now. Not least because they are much cheaper than they used to be.
Anyone any ideas or practical experience?

David

Hi there,
I cant' claim any originality for he use of the ACK bytes, use of some kind of handshake response is common to make sure a data packet is received, and to regulate the flow of data. I didn't intend to have a comples return message structure simply because the longer the ack message the longer the time to send/receive a data packet pair. Originally it was going to be a single byte, but adding a message type byte to the 'Tx' message to allow for servo commands, fail-safe settings etc. made me think that it mad sense to expand from 1 to 2 bytes for the return ack. The idea was that this would have 8 signal bits or alarms to play with rather han attempt to make a complex telemetry link back. At the minute I have 'Rx time out', 'fail-safe actvated' and 'Rx message fault', but as you say other obvious additions could be low battery, low signal strength, high current etc.
The sending of the ACK is not part of the LoRa library, I simply switch between Tx/Rx modes under s/w control, complicated by having Rx & Tx timeouts at both ends. I had to juggle these timeouts to get it to work and to recover, to get it to resync after power or other events.
Also, what I have called the loop time (to send a message packet and receive the ack message) is currently about 150 msec, but quite a large chunk is the transition between Tx/Rx, so even after processing the servo messages there have to be some delays added to ensure that both ends are in sync still. The Slave processes the servo data before sending the ack, so can then switch immediatey back to Rx for the next servo message. The Master on the other hand switches immediatley to Rx after sending the servo message, but reads the joystickes etc after receiveing the ACK message. I've tried to set the Master Rx timeout to about 300msec (i.e. wait for ACK) but the Slave has a longer Rx time out of 2secs (i.e. wait fo the next servo message). The idea was that if the ACK is garbled or missing the Master woud send the next servo message before the Slave timeouts. (latest github has that).
THe other change is to chnage the display to a 128x64 1.3" OLED using the SH1106. Again the Adafruuit library is too large to fit, and the ideal of allocating a buffer for the screen data (1kbytes) ia also not quite possible so I've used a simpler library (ss_oled) and no buffer. This gives me 8 lnes of text so seems OK, again updating one line every 10 message or so. At the minute I have RSSI, Ack message data, SNR, Loop time, RF channel and the top line for events such as timeouts, and the bottom line for converting the ACK data to a set of 8 x 2 letter abbreviations. Again updates in github.
Interestingly, now I have the RSSI at both ends I find they are not the same, one is -67dBm, the other -57dBm but not looked into why or if the difference is significant.

It does rather look as if the pro mini is getting a bit under powered and too little memory for much more, but looking at the new rasberry Pi will have to wait I think. The 3.3V Arduio does use very little power however, and does seem to be just adiquate if the software libraries are chose to be efficient and no fancy features. I think a fancy display on the Tx would be tricky.

On the hardware side I almost have a PCB design some 40mm x 110mm that has the mini-pro, RF module, RF channel hex swith, 5V to 3.3V PSU, 16 digital I/O and 5 analogue inputs. The aim is that this could be cut in half for the slave if the 16 digital I/O and 4 analogue are not needed. I intend to use the PWM module for the actual servo drivers, but connected via I2C bus, but may try and keep the full PCB as I can add in other alarms or voltage/current inputs, but we'll see. Not yet sent of the PCB order yet mind you!
THe 5th analogue input is via a resistive divider and direct to the pro mini, but is intended to measure the 12V battery directly, but havent actually tried that yet.
The next step once I have the PCB is to build a useable Tx with 2 x 2-axis joystick, 4 x 3 position switches (i.e. centre off) a trim on at least 1 joystick and the display. My thoughts for the switches is to have each switch having a centre off position so one switch drives 2 digital channels, that could the drive 2 relays and a perestalitic pump for the ballast tanks with the realys provinfding the fwd, off rev pump control.

I do intend to go back and try to get FSK working looking at the varous seggestions, once I have a working system, as that would be 'just' software (Ha Ha). It would interesting to try dry testing with our various test systems all co-located to see what interferrence we actually get, but I guess that will have to wait.

Hi,

I've been doing some work on FSK trying to get telemetry working - so far without success. I  haven't found it easy to switch the RF69 module between transmit and receive. Thanks, Simon, for the suggestions about SLEEP etc. The RadioHead library has the ACK function built in but I found RadioLib easier to use, certainly initially to get data to be sent and received.

I will plod away (it IS an interesting challenge!) for a few days before I post any code.

BUT I do have the following ready for underwater range testing (without Telemetry) at the pond hopefully within the next week or so, Coronavirus "roadmap" permitting:

- The DIY RX using the SI4432 (RF22) chip on openLRS
- The FSK RX and TX using the RF69 on the software I've already posted on Github.
- The LoRa RX and TX using the RFM96 on the software I've already posted.

I've just uploaded the code for later RX 2.1 and TX 2.6 sketches which work for radio control but the Telemetry function is not working as yet. Any help would be appreciated.

https://github.com/rdforrest

I am very pleased to say that I have finally carried out the underwater range trials to compare the various UHF WiFi modules for use in model submarines.

I would like to thank various people involved in the project. (Could I start with our wonderful NHS and vaccine developers who are providing some light at the end of the pandemic tunnel?) Tim for suggesting the use of openLRS on these 400Mhz frequencies and LoRa for use in model submarines. Jonathan and Simon for their valuable contributions to chip selection and WiFi software.

The trials have come up with surprises and point the way forward in the development of this technology for our hobby. The results are freely available and, quite frankly, anyone wishing to develop these systems for commercial purposes is more than welcome. One of the problems for model submariners is that our radio hardware has been left behind by surface modelers who are using equipment at ever higher frequencies. Tim Senecal first spotted the "Goldilocks" frequency of 400 MHz. (Low enough for water penetration and high enough for telemetry.)

First of all the lake at Barrow in Furness. The receiver was submerged to a depth of 0.5m at Point (1). The furthest distance transmitted was at Point (7) about 70m range. (I can't wait to tell you which system this was!)



This is the waterproof tube containing the receiver being tested. All the aerials used were identical commercial 433MHz ones. They were horizontally aligned for the RX and TX. The received signal was indicated by a cluster of bright LEDs at the surface which came from a switcher attached to the rudder output.



This is the weight and float arrangement. Lockdown produced many empty tonic bottles! The receiver tube hangs about 0.5m deep. The lake is fresh water.



You can see the blue illuminated LED.




This photo shows the position and orientationof the unit.



This is what a range of 70m looks like. The receiver is close to the white buoy in front of the boat house. At this distance I needed binoculars to see the LED. In practice you would not be wanting to control a model at this distance.




The Results:

Trial (1) Hobbyking Orange Rx and TX module. openLRS software version 3.8.8
The signal was lost at Point (5) about 20m range.  Fairly typical and usable. (The TX module "lost packet" alarm had started beeping at about 5m)

Trial (2) Hobbyking Orange TX module with the home made DIY receiver detailed in this thread, using the RF22 /  SI4432 chip and openLRS software version 3.8.8
The signal was lost at Point (2) about 5m. This was a very poor and surprising result.

Trial (3) Home made DIY TX and RX  detailed in this thread, using the RF22  /  SI4432 chip and openLRS software version 3.8.8.
Very poor range, less than 5m.

Trial (4) Home made DIY TX and RX using the Adafruit RFM69HCW  with FSK modulation. Software versions TX_2.2
& RX_1.8.ino. Available at https://github.com/rdforrest.
The signal was lost at Point (6) about 30m range. Very good.

Trial (5) Home made DIY TX and RX using the Adafruit RFM95W with LoRa modulation. Software versions TX 2.1 and RX 2.1  Available at https://github.com/rdforrest.
The signal was lost at Point (7)  about 70m range. Excellent.

Conclusions:

The poor performance of the DIY openLRS was a surprise. Could it be poor chip quality? In any event, the RFM69HCW chip provides much better performance. (As originally suggested by Jonathan.) Any development work is best devoted to software for this chip.

Don't bother building an openLRS TX or RX, in my opinion, but buying commercial gear is now difficult. Hobbyking still have no stock of RXs.

The RFM95W with LoRa modulation (As originally suggested by Tim.) offers really good range and shows real promise  for underwater use. The only downside maybe Jonathan's point that it needs a very high bandwidth and so may have problems in getting regulatory approval.

Later edit. Typical Receiver (the LoRa one in this case):

Good trials!
Looks like a DIY combo is still the best. For completeness did they all use the same RF bandwidth & effective data rates, or at least comparable? There seems to be such a wide disparity between them.
I'm hoping to do some similar tests in the local canal soon, but I am waiting for a new PCB to integrate all the bits into a more manageable unit, but it looks as if your Rx is going to be a bit smaller. I'm hoping to be able to use the RSSI displayed on the Tx plus ack message as my pass/fail criteria rather than squinting through the rain/mist/snow/sandstorm at a (hopefuly) far distant LED!
On the question of channel usage have you tried running them simultaneously, though I think I got the impression that the base RX was the same, just different RF modules.
Again if I get a 2nd RF/arduino set I should be able to try that, and see if LoRa realy is interference free from a 2nd Tx/Rx. That would make it easier to agrue the use of more than one RF channel.

Thank you!

Basically all the modules were setup to give full "whack" but they are hard to compare.

The Hobbyking openLRS TX was set to a power of 7 - which I think is about 100 mW.
The DIY openLRS TX was set to 4, because that seems to be the maximum I can use. (not sure why.)
The 69 and 95 are set for maximum power output. The 95 on LoRa had a  frequency set to 458.75 MHz with a bandwidth of 62.5 - everything else on defaults.

LATER EDIT: I have tried running it "on the bench" with an openLRS TX on 458Mhz with no noticeable problems.

The LoRa setup seemed to be the one that shows the most promise for model submarines without taking into account bandwidth restrictions, number of simultaneous users etc.

And the days of squinting through binoculars in the snow are over!

I've just posted a new version of the LoRa software on Github:

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

This includes some telemetry providing RSSI and using the excellent INA219 chip for voltage and current.

I have bought two PCA9685 chips for servo control (Thanks for the suggestion. Simon.) but I didn't need them in the end because I found I could use ServoTimer2 software for servo output without interrupt clashes. This keeps the RX nice and small. (really important for model subs.)

I have switched to using the RadioHead library. I find it easier to use and the telemetry function was easier to code. (I just adapted the Adafruit example.)

No, I haven't tried operating two or more setups together. (SEE LATER EDIT ABOVE) This and the bandwidth regulations  needs to be looked at. I think that you and Jonathan have a better grasp of this.

If it is any help, model submariners are usually "solitary beasts". In the 5+ years of using openLRS we have only ever had two users together and this includes some of the major model submarine events in the UK.

This may change if the supply of 40MHz sets continues to fade. (I am pleased to see that they are starting to offer refurbed  75 and 40 Mhz sets in the US.) (Also pleased to see that Tim S is posting about 433 MHz in the US. He spotted the "Goldilocks Frequency Gap." (Could that become the GFG ?!)
.

Some photos  of the LoRa radio system on trial at Barrow this Sunday:

The Turkish Nordenfelt is the test model. The model has been fitted with a LED cluster to show a channel on and off. String attached for the first attempt!
The controls show a lot of latency or lag but this didn't seem to be a problem controlling this type of marine model.



You can just see a red LED under the water to the left of the string!



This indicates the maximum range I tested. LATER EDIT: To answer Tim's question- an arrow added. I submerged only about 3 times. (Using a Lipo and I still don't have battery voltage on telemetry so I was playing it safe.)








Video of the sub under control:

https://youtu.be/mGyrBRliyDo

David, i guess i am blind :) ...   where in the photo with the tugboats is the Nordenfelt?   how many submerged runs did you try?   other than that, this appears to be an excellent test/setup/option.


on to another of my discoveries... useful for the US...   expressLRS..  it is a 915mhz lora based successor to our OpenLRS.  i have ordered a TX module and a receiver.  i will post results of my tests when they arrive, which could be months... they are coming from china via banggood...   the european equivalent is the 868 model... and i doubt it would work better than this 458 lora you are now testing.

https://www.banggood.com/Happymodel-ExpressLRS-ES915TX-915MHz-Ultra-Long-Range-Transmitter-Module-and-ES915RX-0_7g-Receiver-for-Radiomaster-TX16S-Jumper-T12-T16-T18-Transmitter-p-1814915.html?cur_warehouse=GWTR&ID=6303125&rmmds=search

a youtube search found this...   in which he claims airborne testing was stopped at 33 kilometers, not due to loss of signal, but fear of losing aircraft

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

Some more photos taken this Sunday using the Turkish Nordenfelt sub using LoRa. Your original  suggestion of LoRa could pay dividends, Tim!

This illustrates the phenomenal range. (About 100 m with standard commercial aerials at a receiver depth of about 6 inches.)

This range is much more than anyone would  actually need. I could only just see the model and LEDs using a monocular. I think that development can now concentrate on optimising the LoRa system. (Minimizing the power and bandwidth requirements to suit our application in submarines.)



The sub and  LED cluster for testing (Oh and the white "Pinger" module - just in case! ) The latest version of the software has telemetry with battery voltage appearing on a separate screen on the transmitter.



Out and about under LoRa:



Thanks for the links to new LoRa developements, Tim.  Amazing range. It is just a shame that the frequency keeps on heading upwards from what we need for subs. I just hope that chip manufacturers continue to offer 433 MHz. (You would think that it has enough use worldwide. ) (I have re-edited my previous post to answer your questions, Tim.)

David, all of this is excellent news. I hope to follow soon with my own 915mhz lora testing... but don't hold your breath, it could be months before i get time to try anything.

Hi all,
I managed some testing of my own over the weekend.
I now ahev a PCB that will act as Tx(master) or Rx(slave) though the slave could be reduced in size when I get to a real model.
I'm using the SX1278 for RF (458MHz, chanel 9, LoRa mode @ BW = 62kHz so about 3 channels), 4 x 12-bit ADC I2C module to read the 4 joystick channels and MCP23016 I2C IO expander to provide 8 x digital channels & 8 x digital trim inputs for the joysticks. Obviously the ADC module and the IO expander may not be required in the Rx so that he bit that can be cut off the PCB, but at the minute its all whole as it also allows a small LED display that is usefull for debug. The Rx uses a PCA9685 to drive the servos & LEDs as it can drive these at a higher voltage directly. Code is on github for reference.

Testing comprised a rubber gasket type sandwich box, a brick for ballast, thin rope for retrieval and gaffer tape to hold it all together. Test site is a canal basin just up the road (Hickling basin) that has the advantage of a tea room so my wife gave assistance by holding tihe rope whilst I waked away to see how far I could ge before the 'Rx fail' came up, since there is an ack message in response to each command frame. I had noticed that the Master reports -67dBm whilst the slave reports -57dBm, so it appears that the Slave RF module is generating less power.
This is supported by the fact that the failure mode is driven by the Master no longer receiving the Ack message. Walking back a bit there were no error flags from the Slave to indicate that the slave lost messages (timed out) or triggered the 'failsafe'.
The range acheived was about 79m, (compared with 104m in a previous test waking round the village with the Rx in the back bedroom) so similar to David, which is comforting as it appears I'm on the same road!




It could possibly be extended by selectng the 'best' RF modules, but 10dBm is a lot of variation.
In terms of message rate I'm gettig about 1 message frame every 150ms, so some 6 updates every sec, though the serveos are runing at 20msec updates as usual, I was hoping for more, but the killer is the turn round tme for the RF modules, having a 2-byte ack message requires constant switching between Tx & Rx which I think is some 20msec every time. I also noticed that the reported frequency error can be 2kHz or more, (the Tx has a display circulating between RSSI, SNR, freq error and loop time, with an update every 10 message frames or so) so trying to get down to 25kHz bandwidth could be even more tricky with the fairly low stability xtals fitted.

All seemed to go well (nice cakes as well!) but I have a feeling there is s possible freezing issue with the Tx, in that the displays didn't seem to be updating at one point, but there is currently no positive indcation or heartbeat.
I also realised after David mentioned it in his tests that I have no audible alarm, so as the aim would be to be watching the model not the display (faint in bright sun anyway) I want to add a audible alarm to a spare arduino pin. As it happens I have a spare pin used in the Rx for the 50Hz calibration from the PWM module and an input intended to measure the Rx 12V battery on a spare analogue input pin. on the Tx I could remove the potential divider chain and have a direct output. In fact I may use an i2c module that measures voltage & current in the Rx anyway, but it only goes to 3.2A though changing the current sense resistor could push that up, but thats for the next stage and migrating to the 'motor' forum!




I've tried to attach some photos, but not sure if its worked, generally I'm not a social media type, but happy to share any details.

Hi,

I have been away from this topic for a while as I completed another project so just catching up on everyone's progress of which there looks to be quite a lot which is great to see

I am about to dust of my project and commence where I left off.

I have a question - what antenna are you using? - Are they 433Mhz Rubber Ducks?

Regards
Jonathan

Hi,
mine was actual 458MHz max freq, part RF00664 from CPC farnell. I added an SMA bulkhead cable for the Tx so the antenna was fixed to the case not the RF module so as not to put too much mechanical stress on the module connector as its only fixed with solder. Cable was RF00749 again from CPC farnell.
Just noticed that that range of antennas (antennae?) have 433MHz & 458MHz but I got the 458MHz as the nearest as I'm working in the 458-459 RC band.
Think about it that might be why I get 10dBm difference in signal strength if the antenna are working just at their max frequency, could be tolerance issues, but without a bigger sample I'm not sure.

Have you come across SDR dongles (Software Defined Radio) - you can get them from £10 - ££££ - the software is free

They come in various guises and would allow you to visualise the RF signal in real time which might add a level of diagnosis as to what is happening in real time

An example

https://www.essexham.co.uk/realtek-sdr-dongle

https://www.youtube.com/watch?v=7EiRZfw8xxU

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

Regards
Jonathan

Greetings! I have been using the rubber ducky aerials which come with the Hobbyking openLRS modules. There is a photo of one a few posts back. Apparently they are fairly rubbishy but they fit well in a submarine. Apparently they do incorporate a ground plane which forms part of the connector. They are for 433 MHz of course.

There has not been much study on underwater aerials (That I can find anyway) and I would be interested if you chaps had any observations? The following extract is from a post I made on the SubCommittee (I hope you like my attempts at American English!) Forum a few weeks ago and it gives a link to the only good article I have seen (the one by Elin - Sorry about the tenuous links but we have no way of putting pdf files on this forum.)

"The antenna behaves in quite a different way when positioned horizontally, underwater, anyway. The best reference on this (if you don't mind some math!) is a US writer in this old British AMS mag:
"A very informative article by John Elin about antenna. (Best article I've ever seen about underwater antennae. Conclusions are TX height important, water conductivity important, shortened aerials may be better in water.)"
AMS 1986 6OCR:
IN:
https://www.facebook.com/groups/AMSmembers/files

"
There is also a good article by Butler (My thanks to John Robinson for pointing this one out):

http://users.tpg.com.au/users/ldbutler/Underwater_Communication.pdf


Very interesting point about SDR dongles, Jonathan . I hadn't thought of that, even though I played with one a couple of years back. The only monitoring system I have at the moment is still an openLRS TX with the frequency scanner option.

By the way, I am thinking about changing the thread title. We are not really talking about openLRS now (UHF radio control on 458Mhz perhaps??)

David

After some expert tuition I'm having another go at uploading some photos.
The basic board uses the DRF1 RF1278 module mounted on an adaptor with a 3.3v arduino mini-pro mounted underneath..


Though the board can be used as an Rx as is, it can be cut down to remove the 4 channel analogue & 16 digital inputs to give:


The complete Tx is a bit agricultural but does work, though ot all the swicthes are fitted yet:



As mentioned in my earlier post I get a range of about 75m from 0.5m underwater with a view of:



Since then I've tweaked the s/w to add a sort of visual heartbeat (flashing '+') on the Master OLED display and changed digital channel 6 so it is 'on' unless the power fails or channel 6 is activated. My idea is to have a float & string that is retained untill disatster time when it should float to the surface and show the models position.

The 4 swictches in between the joysticks are centre off switches so provide the 8 digial controls, so they form pairs of controls.
There are 2 extra holes under the joysticks, thats because I decided to invert the whole layout after drilling some of the holes.

Whilst not part of the rage test, I use a PWM module to drive the servos, as it can hadle the 6v servo power directly, where as the arduino is 3.3v:

Nice hardware, Simon and I rather like the transmitter! Also good to see that you are getting a similar range at 0.5m depth. Hickling basin looks very nice too.

I have changed the title of this thread to reflect further developments. I hope this is OK?

Jonathan' s comment on SDR set me to dusting off my 2832U dongle. (I last used it for broadcast FM a couple of years ago but I found it fiddly to set up drivers etc)

BUT it produces interesting results (which I am still trying to interpret!) on 458 Mhz. (The drivers are still fiddly. I had to install some .NET software (Windows 10 prompts you for it.) and then go back to the installation batch file to get it to work.)

This is the LoRa result:
The waterfall gives horizontal lines at about 1 second intervals. The yellow line in the top box shows the  "LoRa chirp" at about 1 second intervals and presumably the pulse width  shows the bandwidth of 125kHz  for this software setup. With the RX on, I think I have noted a telemetry return - second horizontal line at 10 second intervals. (Not shown in the image below.)



And openLRS:
Same settings as above and gives  frequent horizontal lines. The frequency hopping peaks are showing?



LATER EDIT: A better screen grab of the LoRa software. This shows the LoRa (large!) bandwidth. Also shows the signal pulse every 1 second and the telemetry return pulse every 10 seconds. I suppose the main hope for the system is that there are large gaps between pulses and the next step is to try trimming the bandwidth. (Simon, I think, uses half that shown.)

Hi David,

Good to see that an old friend has been dusted down - just remember that you will kiss good bye to a few hours of your life if you read any further :)

I am sure you can use that dongle with other software

See

https://www.youtube.com/watch?v=5Czo_CYd94s



OR
SDRuno/SDRPlay - I use this

https://www.sdrplay.com/you-can-use-sdruno-with-an-rtl-sdr-dongle-new-video-guide/

So can owners of many other SDRs which support an EXT/IO interface.  We’ve just released a new video guide to using the “SDRuno EXT/IO edition”:

Compatabilty

http://www.radioforeveryone.com/2016/07/rtl-sdr-with-sdruno-first-steps.html


The SDRuno version allows you to change waterfall types which may help

https://www.sdr-radio.com/

Interesting info on commercially available equipment copied over from Facebook:

Adam Fraser
David Forrest
If I was looking to buy another radio specifically for 433mhz
any thoughts which TX should i consider? … See More
· Reply · Share · 3d
David Forrest
Author
Admin
All a little finicky, I'm afraid. It was much easier when the Hobbyking Orange openLRS RX and TX modules were both available. You can still buy an Orange TX module for a Futaba but the RX is still (and probably will be for ever!) out of stock.
The basic requirement for all the above is to be able to access the pcm output via the Trainer socket for example. But you are then into DIY equipment, I'm afraid.
What would be nice is for someone to offer some commercial equipment for 433 or 458. The technology is all there but model subs are a small, niche market. Sorry for a not very satisfactory reply.
· Reply · Share · 3d · Edited
Adam Fraser
David Forrest
I see. I originally considered this
https://m.aliexpress.com/i/32855545673.html
M.ALIEXPRESS.COM
m.aliexpress.com
m.aliexpress.com
· Reply · Share · 3d
Adam Fraser
David Forrest
https://images.app.goo.gl/SKL2CtK1SQA2Nb936
Image: ImmersionRC EzUHF Receiver 433Mhz 8 channel diversity Long Range ...
GOOGLE.COM
Image: ImmersionRC EzUHF Receiver 433Mhz 8 channel diversity Long Range ...
Image: ImmersionRC EzUHF Receiver 433Mhz 8 channel diversity Long Range ...
· Reply · Share · 3d
Adam Fraser
David Forrest
https://www.buildyourowndrone.co.uk/immersion-rc-ezuhf...
Uk based seller
ImmersionRC EzUHF Receiver, 8 Channel Diversity. Long Range Radio Control For FPV Pilots Build Your Own Drone
BUILDYOUROWNDRONE.CO.UK
ImmersionRC EzUHF Receiver, 8 Channel Diversity. Long Range Radio Control For FPV Pilots Build Your Own Drone
ImmersionRC EzUHF Receiver, 8 Channel Diversity. Long Range Radio Control For FPV Pilots Build Your Own Drone
· Reply · Share · 3d
Adam Fraser
David Forrest
I’m not sure if this would be suitable
Instead of the Orange?
https://www.buildyourowndrone.co.uk/immersionrc-ezuhf-jr...
I appreciate the response. It would be good if 35mhz was an option.
ImmersionRC EzUHF JR Module, Longer Range Radio Controller 433-459Mhz Build Your Own Drone
BUILDYOUROWNDRONE.CO.UK
ImmersionRC EzUHF JR Module, Longer Range Radio Controller 433-459Mhz Build Your Own Drone
ImmersionRC EzUHF JR Module, Longer Range Radio Controller 433-459Mhz Build Your Own Drone
· Reply · Share · 3d
Adam Fraser
Main supplier
https://www.immersionrc.com/fpv-products/ezuhf-jr-module/
EzUHF JR Module Transmitter – ImmersionRC Limited
IMMERSIONRC.COM
EzUHF JR Module Transmitter – ImmersionRC Limited
EzUHF JR Module Transmitter – ImmersionRC Limited
· Reply · Share · 3d
David Forrest
Author
Admin
Hi Adam,
I don't know about this particular setup.
I suggest you have a careful look through the thread on the AMS forum for any mention of it. Tim Senecal has been looking at various commercial options on there.
Agreed about 35 Mhz, but in some original discussions with them, it was clear that aircraft modelers jealously (and correctly) guard this frequency for safety reasons.
· Reply · Share · 3d
Adam Fraser
David Forrest
I found this on the site
It mentions uk specific band.
May be an image of text that says '18:09 PRODUCT SPECIFICATIONS Retail Price ($USD): $99.00 Initial Release Da:Jan 2014 Standard: JR Module Format R/C Channels: Maximum of 12 (future upgrade o16) 16) RF Impedance: 50 ohms Power Output: 500mW (27dBm), with 200mW low-power mode Modulation: GFSK Hopping: 20 40 slots, 2MHz, or 20MHz frequency spread (Extreme Hopping) Frequency Band (Std. Firmware): 431-433MHz, 433-435MHz, 435-437MHz, 436-438MHz, 430- 450MHz (Extreme Hopping) Frequency Band (UK Firmware): 459MHz Power Requirements: 2s-3s LiPo (6ν 13v)'
· Reply · Share · 3d
Write a public reply…

Tim Senecal
my understanding is that the wolfbox items, if you can actually get them (they never seem to be in stock) are clones of the Hobbyking orangelrs parts. https://www.aliexpress.com/item/32815987085.html...
64.9US $ |WOLFBOX LONG RANGE UHF 1W 100MW 433MHz TX+RX Transmitter +Receiver Kit JR Module Compatible with X9D/X12S/ X7/THX9/9XR|long range uhf|jr modulelong range - AliExpress
ALIEXPRESS.COM
64.9US $ |WOLFBOX LONG RANGE UHF 1W 100MW 433MHz TX+RX Transmitter +Receiver Kit JR Module Compatible with X9D/X12S/ X7/THX9/9XR|long range uhf|jr modulelong range - AliExpress
64.9US $ |WOLFBOX LONG RANGE UHF 1W 100MW 433MHz TX+RX Transmitter +Receiver Kit JR Module Compatible with X9D/X12S/ X7/THX9/9XR|long range uhf|jr modulelong range - AliExpress
· Reply · Share · 3d
Adam Fraser
Tim Senecal
Thanks for joining in and the information.
Do you know anything about the
ImmersionRC Tx/Rx?
· Reply · Share · 3d
David Forrest
Author
Admin
And there he is! Brilliant!
· Reply · Share · 3d
Adam Fraser
May be an image of text that says '18:09 PRODUCT SPECIFICATIONS Retail Price ($USD): $99.00 Initial Release Da:Jar 2014 Standard: JR Module Format R/C Channels: Maximum of 12 (future upgrade o16) RF Impedance: 50 ohms Power Output: 500mW (27dBm), with 200mW low-power mode Modulation: GFSK Hopping: 20 of 40 slots, 2MHz, or 20MHz frequency spread (Extreme Hopping) Frequency Band (Std. Firmware): 431-433MHz, 433-435MHz, 435-437MHz, 436-438MHz, 430- 450MHz (Extreme Hopping) Frequency Band (UK Firmware): 459MHz Power Requirements: 2s-3s LiPo (6v- 13v) ELUHF ansmitter'
· Reply · Share · 3d
Tim Senecal
Adam, i do not have any knowledge on them, but, for simple "will it work" and adding to the base of knowledge, i may just buy one set of ImmersionRC EzUHF parts to verify that they will work for our needs. it would be nice to add another entry to our list of stuff.
· Reply · Share · 3d · Edited
Tim Senecal
well, that was easy, i have an ImmersionRC JR module and an 8 channel receiver on order from a US Ebay store (local shipping time). I will post when i get them and can test them.
· Reply · Share · 3d
Tim Senecal
Adam, am not British, so for me, i look for US sellers... found one that is an FPV/Drone retailer, and he was selling brand new equipment at $86 for a full 8 channel servo receiver and a JR transmitter module including shipping. there was nothing not to like, so i bought it. it should be here in a week or less, so maybe two weeks and i will post here, and probably the AMS website as well. while not as cheap as the Hobbyking stuff, it looks to not need all the wizardry to get a reliable working setup.
· Reply · Share · 3d
Adam Fraser
Tim Senecal
I look forward to seeing/hearing your results.
· Reply · Share · 3d
Adam Fraser
https://youtu.be/TxekEdilVeA
Immersion Review
[REVIEW] ImmersionRC EzUHF JR Module Setup
YOUTUBE.COM
[REVIEW] ImmersionRC EzUHF JR Module Setup
[REVIEW] ImmersionRC EzUHF JR Module Setup
· Reply · Share · 3d
Adam Fraser
https://youtu.be/tt-qZmIEJfI
Tx module comparison
EZUHF JR Transmitter Module vs Regular EZUHF TX from ImmersionRC
YOUTUBE.COM
EZUHF JR Transmitter Module vs Regular EZUHF TX from ImmersionRC
EZUHF JR Transmitter Module vs Regular EZUHF TX from ImmersionRC
· Reply · Share · 3d
Tim Senecal
the EZUHF TX module and RX have passed their first tests... 1) they both power on, 2) they bind together, 3) they operate as expected after binding. now to put them in a submarine.
No photo description available.


Tim Senecal
well... dang. first bit of bad news: ImmersionRC no longer actually manufactures these units. basically any remaining new stock will never get replaced. not sure how long this has been a "thing"... but i discovered this trying to download a pdf of the owners manual, and windows PC software used for advance configuration and firmware updates (kind of like the OpenLRSng configurator).
· Reply · Share · 1d
Tim Senecal
second bit of bad news: for all intents and purposes, there is no telemetry downlink to the TX module. the system as envisioned does support a form of telemetry, but it is designed to be used in FPV systems... ie, the control receiver feeds its data to an FPV transmitter, then you see it in your goggles while you are flying your drone. won't work for submarines.
· Reply · Share · 1d
Adam Fraser
Oh no..
Sorry Tim Senecal
· Reply · Share · 1d
David Forrest
Author
Admin
That's a great shame, Tim. This always seems to be the problem with commercial gear - everything is so short lived and also the design is dictated by flyers needs.
· Reply · Share · 18h
Tim Senecal
i don't mind not having telemetry, as long as my failsafes have been set correctly... i will also need to see how long it takes to re-establish a link after loss. the other issue isn't as big now as it will be in a few months/years. i just checked, there are at least 25 listings for this stuff on ebay, with 90% being new. prices are reasonable, and the split is pretty even between TX and RX. I could easily replace all of my existing OpenLRSng equipment with about $300 worth of this stuff.
· Reply · Share · 17h
Tim Senecal
I think the real issue here, as far as the US is concerned, is that the 433mhz stuff is frowned upon due to the need for a HAM license. 915mhz and 2.4ghz do not need any license. Also, a lot of work has gone into creating long range versions of 2.4ghz equipment by some of the bigger manufacturers (like FrSky)
· Reply · Share · 17h · Edited
Tim Senecal
a quick look.. the ebay seller i bought my stuff from lists 8 tx modules in stock, and "more than 10" rx in stock... and they are not the only seller with similar volume. so there is still hardware available in the retail channe

Just a quick update for completness, I added a small sounder and a 'driver' (74HCT02 quad NOR gate) to isolate the load from the Arduino and drive it from a spare pin on the TxRx board. Pin was actualy intended as an input on the Rx to calibrate the PWM 20msec frame,so was unused in the Tx version.
The code is nothing sophisticated, just a small function that generates a given number of audio tone cycles @ 1kHz. OK it blocks whilts generating the tone, but I only generate the beep on either power up or when the Tx looses a packet back from the Rx. so a small delay of some 100msec is not going to be significant.
I've also drilled a few holes in the back of the case to let a bit more sound out, the sounder is simply glued to the inside of the case as the volume is not that loud but should be OK.
We'll see when I have a sub to try!
Updated code to github s well.

Today i finally got time to take my trusty Norbert Bruggen Delta off to the pond with the ImmersionRC ezuhf setup. I had already setup the transmitter module for 8 channels of output, with it connecting to the Taranis x9d radio via the JR style socket on the back of the radio. comms between the transmitter and the module are via PPM (see image), and binding is done similarly to the OpenLRS equipment (press bind/failsafe prior to power on to bind, press same button when tx and rx are bound after power on to set failsafe)

Nothing eventful at all about it. It ran perfectly fine. Granted i did not try anything exotic. I put the sub in the water, ran it around on the surface for a few loops of a 50 x 10 foot oval, then started the pump to submerge it. please note that the Delta at surfaced trim has almost none of its body above the water. At that setting, the radio is already about 4" below the surface. After getting the sub 2" to 3" below the surface, i then ran it around the same basic oval course, with no issues. i then used the diving planes to get it about a foot below the surface and ran a smaller oval further from shore (the slope of the pond's bottom required i run it at least 20 feet from me) the pond i ran at was a first time for this sub, the water was surprisingly clear at least 2 feet down. again, no issues, and i never noticed failsafe kicking in. I also need to mention that all of this was being done with the TX module power setting set at "low".

I will need to take the sub over to the local pool to both test it in a chlorinated environment, and to see at what depth (the pool has a max depth of 8 feet) the failsafe kicks in. on the OpenLRSng 433mhz equipment, the failsafe did not kick in, even at the 8 foot depth. I have attached a few photos of the equipment. i didn't take any photos or video at the pond... not enough hands.

Taranis x9d setup screen


ezuhf module in Taranis


ezuhf receiver in submarine, Futaba 75mhz, ChipLRS 915mhz RX, and HobbyKing OrangeRX OpenLRS rx for comparison