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

Hi Jonathan,

The telemetry is a serial connection. (For openLRS the baudrate is set in the Configurator which should also be set to "Passthru".)

My thoughts on what you need to include:

- A general point is that latency is less of a problem for model subs than drones. (Things don't happen so quickly!)

- 8 channels should be enough.

- binding (I wonder if just setting a personal code in configuration would be enough? I now have the same bind code in all my TXs.)

- channel hopping within a set legal bandwidth.

- some method of setting configurations. (Editing code would be a bare minimum.)

- loss of data indicator. (The odd beep lets you keep the model in range. Continuous tone gets you worried. I like the model being "talkative" this way although it can make the uninitiated think it is signal loss.)

- telemetry (but needs much less data than for flying)

- failsafe (with an audible prompt to make sure that you set it - easy to forget with the result that your sub stays sunk!)

I think that is about it. I look forward to openSUB or whatever!

David

David,

Thank you for ideas and suggestions. Some of these echo thoughts I have already had.

Regarding things like binding I might go down the line of mirroring the concept of pressing a button on the receiver to bind to the RX but not to start with.

I currently have a few setups where I have more than 2 transceivers in one system all using the same Encrypt Key - works a treat.

I think having a simple "config" file that gets included in the complilation is the way to go

Basically some long time ago I started using a library written to interface to various transceivers- written, supported and developed by an active, quite large group of people.

They use the library to connect to sensors for things like weather stations etc

https://lowpowerlab.com/category/rfm69/

https://lowpowerlab.com/forum/

It is feature rich and mature solution. I simply bolt on my bits either end and don't have to worry much about the comms side - that is once I got it working originally as you do have to navigate clashing interrupts!! (Yours not their's!)

The reason I have such confidence is a simple working solution relies much on the work the low power labs crew...

Jonathan

Many thanks for links to lowpowerlab, Jonathan - it looks very interesting and promising.

I particularly like your approach of using off the shelf software for the comms and simplifying the rest. I don't think that the model submarine community could provide the same human resources for software maintenance as the flying community. (It is a numbers game.)

I wonder if this will also mean that your approach will be less dependent on hardware selection? Scope for including LoRa etc? All we are wanting to do is reliably send a ppm stream out and get some telemetry back.

David

Hi, Tim and guys, look like I got a lot of catch up to do.
Fung

Hi guys,
I've recently joined, but currently have no sub and no radio. I work in electronics and many years ago I started a UHF rc system, but how the technology has changed! I decided it was would be easier to start by building the radio gear, and did think about designing a 40MHz system but due to a job change I no longer have access to the test kit needed to adjust the coils etc.
As a result I've started on a system based on the arduino (pro-mini 3.3V 8MHz) as the brains and the SX1278 RF chip embedded in a DRF1278 RF module, as though intended for the spread spectrum mode it can be used narrow band mode needed to be legal. Also there is an adaptor board and a lot of library software available from Stuart Johnson via tindie.
I'm not sure about using the openLRS software, but I intend to look at it once I have basic operational radio hardware.
I'm thinkng of using addtional analogue input chips to support at least 4 axis of joysticks and the PCA9685 PWM chip to drive the servos, but we'll see!
As I'm starting from scractch I have no Tx to canabalise for the digital generation so it seemed easier for me to start from the raw hardware, mind you I may regret that!
At the moment I am still assembling the pro-mini & adaptor boards before connecting the RF modules, but I will let you know.

As a thought, has anyone tried adding a serial link between the Rx and say a pool-side laptop, phone, or other terminal? either bluetooth, infra-red or even via a waterproof connector? It would seem to allow easier configuration of RF channel, node ID (for binding), failsafe settings etc. The easy way would be via switches on the Rx, but that of course means physical access to the Rx.
regards
Simon H

I am too new at this forum.

May be to save some time start with OpenTX/Er9X control base system. Easy to find used or new boxes.

Simon,

its nice to see a new "face"...

a few points to bring up from some of your questions...


in the ancient times before i switched to OpenLRSng... i had tried somethings with older 75mhz equipment. specifically the futaba/robbe transmitters and receivers (as well as others) offered "DSC" on their receivers. DSC stood for "Direct Servo Connection" that meant you could run a cable from the transmitter's trainer port directly to a 3 pin port on the receiver (the port labeled "DSC"... if the receiver didn't have a port labeled "DSC", the receiver didn't support it)

long story short, i made a 30 foot DSC cable to test on one of my subs... it worked... but had issues... like any other modern tethered rov, the tether will find anything to snag on.

other questions you bring up... i fear that building both a transmitter and an rf deck will create too many unknowns. is it the transmitter that is not working right or the rf deck... build a test rf deck that can decode a ppm signal from the transmitter... using it with a known good transmitter. after you know the rf deck works, build a transmitter.

Hi All,

As Tim says it's good to see new faces. He may have started something with 433Mhz for submarines!

I would also agree with Tim's advice for Simon. At the risk of sounding old fashioned - you need a transmitter box with some sticks on it! Because:

- Laptops, phones etc are difficult to see in sunlight if you are trying to control a sub from them.
- Nice second hand 35Mhz TXs are cheap on ebay. (£30 or so) and for that you get  a nice box with battery, sticks and a trainer port which will give you a ppm signal output. (Cheapsub had a nice description of a "Frankentransmitter over on Subcommittee. Disable the rf side - crystal out and aerial removed as a minimum.)

A further update on the openLRS DIY TX and RX.
The RXs work nicely, and I would recommend anyone to have a go at building them and using them with a Hobbyking TX module. (still available for £4!)
The DIY TX is working consistently but at a maximum power setting of 4. I don't know why! (LATER EDIT: I wonder if this is the "Smart Reset" problem mentioned on https://forum.arduino.cc/index.php?topic=670182.0    All the more reason to move on from this rf module) I have tested this with  2 different rf modules and 2 aerials (including a dipole) and also tried a separate 3.3 volt supply in case they were getting a voltage drop. Range in air is about 2/3rd of the Hobbyking but it is still adequate for a model sub test (when the virus permits!)

Facebook posts:

Jonathan Askey
So 16 channels from handset transmitted @ UHF with ease
Converting 16 channels back to pwm at receiver not without it's challenges - latency is an issue at the moment to work through!....… See More
· Reply · Share · 3w
Adam Carlson
Jonathan, depends on how you do it. The first handful of channels you will likely want to be 8bit, say the first 4. The next channels likely do not need to be that large, especially if they are more generally for switching. With this, you can potent… See More
· Reply · Share · 3w
Adam Carlson
Now if you want to send telemetry back that is a different story, but if you are not staying narrow band, then it is not an issue.
· Reply · Share · 3w
Jonathan Askey
Hi Adam Carlson - thanks for info/comments
I have 2 way comms facilitating telemetry with no latency issue to talk about - indeed it's currently throttled back- been using a platform with this functionality for a few years.… See More
· Reply · Share · 3w
Jonathan Askey
Having scratched the surface with my problem it transpires that the resolution on the pwm on the Taranis radio (OpenTx) I am using is very "lumpy" - it jumps in steps of maybe 20-50us as you move a stick so no wonder my poor servo was stuttering
Cannot work out why the Taranis is so rough - no doubt a setting (mix) but I have given up with it for now and will use a trusted radio instead (Jeti) - one that I don't like connecting to electronics in case I releases it's blue smoke
Another case of looking in the code for the problem when it seems it was actually an external factor...
· Reply · Share · 3w · Edited
Jonathan Askey
16 channels transmitted and working smoothly - the loop code contains just one function that packs newly read ppm stream data into radio packet payload and sends it at a defined interval.
Latency is not noticable - no different to 2.4Ghz setup's
Now to add some of the whistle and bells and fire up the telemetry code.
This is such a simple solution!
· Reply · Share · 2w · Edited
David Forrest
badge icon
I received 2 x DRF1278DM LoRa modules from Tindie in China this morning. (I wanted to have a play with some LoRa stuff and they looked very easy to setup and use.)
I have just got them set up and they are sending serial telemetry (battery volts & amps) back from my sub on the bench. Very pleased!
They WERE easy to setup using the USB to TTL board (DAC02) They are on 458Mhz - I hope it is legal and potentially could be used for LoRa range testing if my sub ever gets back underwater!
How are you getting on with transmission, Jonathan?
· Reply · Share · 5d · Edited
Jonathan Askey
Hi David Forrest - yes I am doing well - good progress - I am going back to basics, with fully documented code so progress is slow.
I may be missing something - LoRa IMHO cannot be legal - the transmission bandwidth is massive!!! LoRa can be up to 500KHz - the DRF1278DM spec recommends 125KHz - possible the default setting?
Do you have anyway of testing bandwidth?
· Reply · Share · 5d · Edited
David Forrest
badge icon
Thanks. Interpreting Ofcom regulations needs second opinions! The document I am using is IR2030 - Pages 87 & 88 cover Model Control:
https://www.ofcom.org.uk/.../pdf_file/0028/84970/ir-2030.pdf
The reason I am trying this is to see if LoRa gives increased range for underwater transmission. If it does, then there must be scope for telemetry at 433Mhz or ,even better, model control at 458MHz?
I am using the default setting for the DRF1278 of 125Khz. I only have the Spectrum Analyzer function in openLRS.
· Reply · Share · 5d
Jonathan Askey
David Forrest - To me it's 100% clear - maximum bandwidth is 25KHz
They are razor sharp in their very detailed specification
They state range 458.500-459.500MHz
There are 40 channels of 25KHz bandwidth
The transmission will spread 12.5KHz either side of the central channel (carrier) frequency (the bandwidth)
To ensure you do not go out of the allocated band they are very clear
Channel spacing 25 kHz.
Channel numbers 1 to 40 inclusive are available with channel centre frequency of 458.4875 MHz plus (Channel Spacing times channel number).
Channel 1 is 458.5125 (BW=25KHz 458.500 to 458.5250MHz)
1 458.5125
2 458.5375
3 458.5625
4 458.5875
5 458.6125
6 458.6375
7 458.6625
.....
35 459.3625
36 459.3875
37 459.4125
38 459.4375
39 459.4625
40 459.4875
So 125KHz Lora takes the bandwidth of 5 channels
Bandwidth is bandwidth and you are not allowed more than 25KHz!!
Sorry....
· Reply · Share · 4d · Edited
Jonathan Askey
David Forrest - if you want to mess with LoRa then I would make sure you go for mid band allocation 458.9875MHz
Loads of people think it's not important to play by the rules with radio - it won't matter, its not important
So much goes over the radio (e.g. remote monitoring ) that organizations pay good license fee money to use parts of the Spectrum - break these rules at your peril....
· Reply · Share · 4d · Edited
David Forrest - if you want to mess with LoRa then I would make sure you go for mid band allocation 458.9875MHz
Loads of people think it's not important to play by the rules with radio - it won't matter, its not important
So much goes over the radio (e.g. remote monitoring ) that organizations pay good license fee money to use parts of the Spectrum - break these rules at your peril....
· Reply · Share · 4d · Edited
David Forrest
badge icon
Steady on, Jonathan! I respect all the regulations and I would hardly be discussing anything that infringed regulations in such a public space, in any case.
An experiment with LoRa this afternoon (a range check using the published telemetry frequency … See More
· Reply · Share · 4d · Edited
Jonathan Askey
David Forrest- apologies - I meant no offence. I have seen on many forums (and another sub one) where people dismiss the regulations as "not a problem", I am not saying that is what you have done or you are willfully breaking the law..
Having used radio as a hobby for 45 years legally it does annoy me when people turn a blind eye - rant over!
Was your LoRa setup @ 25KHz bandwidth?
I am not sure you are comparing apples with apples.
IMHO - the RF22 unit is outdated and ineffcient.
It would be interesting to put an RFM69 up against your project and see how they compare...
I easily get 500-1000m direct line of site without trying
· Reply · Share · 4d · Edited
David Forrest
badge icon
I bought the DRF1278DM modules because they seemed to be an easy route into some experiments with LoRa. They do serial communication "straight out of the box" so I could use them with my existing telemetry setup. (I had them up and working within t… See More
· Reply · Share · 3d · Edited
Jonathan Askey
David Forrest Would an outbound transmission from the model on 433MHz (telemetry) if used alongside openLRS on 459Mhz to control the model cause interference issues?
My experience would be that the close proximity of the 2 frequencies and more specifi… See More
· Reply · Share · 3d
Jonathan Askey
This is a very short video that helps explain LoRa bandwidth
https://youtu.be/dxYY097QNs0
LoRa CHIRP
YOUTUBE.COM
LoRa CHIRP
LoRa CHIRP
· Reply · Share · 4d · Edited
Jonathan Askey
David Forrest - I was interested in your post re telemetry. When you break away from openLRS and are in control of your own architecture things can get interesting.
I have a few projects that use multiple transceivers and processing shared across mulitple Arduinos.
At the moment my shore based transceiver requests an ACK from the model based transceiver every 5 packets.
The ACK model response itself is a packet that can be packed with 60 odd bytes of telemetry data - so is sort of a "free" way to get telemetry back to shore.
I appreciate space is limited in many subs - I am playing with mutliple model based transceivers to see if any merit of a "combined" packet reception - transceivers would be mounted in different parts of the model with antennas in different aspects.
I am also for now testing the merit of an additional shore based transceiver that is working in reception mode only and sniffing the live comms between RC tranny and model
This would be used to show the status/health of comms and also telemetry - it's possible if processing power available to move this back to the main Arduino interfaced to the ppm stream from the RC handset
I have used this concept a few times - when I fire a gun on a warship I have a shore based sound system plugged into a somewhat large PA speaker. The remote sound system has it's own transceiver and sniffs the packets and can trigger sounds accordingly.
· Reply · Share · 4d · Edited
Jonathan Askey
I forgot to mention - I have also included a fail safe interrupt pin tied to an interrupt function on the receiver end.
This would allow you to trigger the fail safe sequence from an external system easily - this could be a sensor of some sort (pressure,moisture,voltage,light), a micro switch etc etc
· Reply · Share · 4d · Edited
David Forrest
badge icon
That's a very useful, clear explanation. (I particularly like the waterfall display to show the "chirp".)
35 & 40 Mhz are much easier to understand - 30 channels or so all spaced 10KHz apart. One person, one channel! (Crystals anyone?)
So on 458Mhz - 40 channels spaced 25kHz apart. Then along comes LoRa spanning 5 channels (Using 125KHz bandwidth). One person 5 channels! Only 8 simultaneous users would use up the entire allocated space? A problem? Not allowed?
I take it that LoRa doesn't use frequency hopping which openLRS does? I have the feeling that frequency hopping is one reason why openLRS works well for models submerged in water. It is really against the laws of physics, (Jim)!
· Reply · Share · 4d · Edited
Jonathan Askey
Quick video of 16ch on UHF to show latency - this is with telemetry streaming back from model (yet to fix the display)
Spent hours working on removing the servo jitter but it's now history!
Sorry about the orientation...(now fixed)
· Reply · Sha

Simon,

both David and i have "been there, done that"... my two attempts at transmitters:

newest: https://www.rcgroups.com/forums/showthread.php?2857877-Pistol-radio

and something a little less "normal":

https://www.rcgroups.com/forums/showthread.php?2191827-tablet-based-setup


of the two, i still use the "pistol radio" daily... its been 5 years since i last did anything with the tablet...

SimonH wrote:Hi guys,
I've recently joined, but currently have no sub and no radio. I work in electronics and many years ago I started a UHF rc system, but how the technology has changed! I decided it was would be easier to start by building the radio gear, and did think about designing a 40MHz system but due to a job change I no longer have access to the test kit needed to adjust the coils etc.
As a result I've started on a system based on the arduino (pro-mini 3.3V 8MHz) as the brains and the SX1278 RF chip embedded in a DRF1278 RF module, as though intended for the spread spectrum mode it can be used narrow band mode needed to be legal. Also there is an adaptor board and a lot of library software available from Stuart Johnson via tindie.
I'm not sure about using the openLRS software, but I intend to look at it once I have basic operational radio hardware.
I'm thinkng of using addtional analogue input chips to support at least 4 axis of joysticks and the PCA9685 PWM chip to drive the servos, but we'll see!
As I'm starting from scractch I have no Tx to canabalise for the digital generation so it seemed easier for me to start from the raw hardware, mind you I may regret that!
At the moment I am still assembling the pro-mini & adaptor boards before connecting the RF modules, but I will let you know.

As a thought, has anyone tried adding a serial link between the Rx and say a pool-side laptop, phone, or other terminal? either bluetooth, infra-red or even via a waterproof connector? It would seem to allow easier configuration of RF channel, node ID (for binding), failsafe settings etc. The easy way would be via switches on the Rx, but that of course means physical access to the Rx.
regards
Simon H

Hi Simon,

Looks like a great project - will track your progress with interest...

Regarding pool side phone/laptop why not use esp32 Web server & wifi (concept example in video below) crude and an early version but I think you get the idea - 2 way comms - no cables!

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

Regards
Jonathan

Spent an age eliminating servo jitter (caused by ppm read from handset)

Progress encouraging - need to get it wet asap to see if it has any merit

16ch with telemetry streaming back - pleased with latency but still room for fine tuning



Regards
Jonathan

Your system is looking very promising.

I wonder if these units to convert PPM to PWM would help you and perhaps make the software simpler? They are working well on the DIY openLRS receiver and at the very least make the servo connections much easier.

JHEMCU SPP 8CH Signal Converter Module Support SBUS PPM PWM Output for Receiver
ID: 1549017 (Banggood UK)
Price:US$8.76



https://www.banggood.com/JHEMCU-SPP-8CH-Signal-Converter-Module-Support-SBUS-PPM-PWM-Output-for-Receiver-p-1549017.html?rmmds=myorder&cur_warehouse=CN

I  can confirm that the DRF1278DM module running alongside an RX running openLRS on 458Mhz does create bad interference. This is only on the bench but my experience says that it will not get any better underwater! So a SEPARATE telemetry channel does not look like a good way forward.

David

Hello David,

I had tried a few ways to get the pwm out of the receiver. Both my trusted devices I have used before did not want to play ball - they worked to an extent and I may revisit to try to get them to function properly - it's likely that the incoming radio packets on an interrupt are cuasing a conflict - something I have come across before and just needs fine tuning/timing rules.

I had spotted the little device you were using serveral weeks back and switched to using it successfully a few weeks ago

A good find David - did not find it easy to solder though - and I consider myself a bit of a whizz with a soldering iron!!

Sorry to hear your interferrence issues.

I have great success with sending telemetry back from RX - what I am considering is using a seperate Arduino to "collate" telemetry data readings and then send them to the main RX board via i2c as a data packet therefore removing any additional processing from the receiver (for at least the duration of experimentation- may be possible to merge functionality back to main RX)

Regards
Jonathan

PWM drivers

https://www.hobbytronics.co.uk/servo-pro-12ch

https://www.adafruit.com/product/815

I am constructing a module to monitor the comms between the shore and the model and the model and the shore - it will remotely "sniff" the radio comms and not interfere with the comms process

It will enable me to remotely view/display the content of the data packets pool side.

My intial intention is to be able to monitor the signal strength in both directions of the radio communication, dropped packets etc - currently the setup will perform an auto transmit retry 5 times to get each packet to it's destination before it moves on.

Once accomplished I will start trials in the water before progressing to see what results this generates

Regards
Jonathan

Hi all,
a few thoughts to chip in with, appologies if you already know it.
PWM output. I hadn't come across that device but I intend to use this one once I've got the RF working. Its a 16-channel PWM chip, intended for LED dimmers etc, but I think it could give about 250 steps for each servo output based on a 20msec frame rate, not sure if thats considered enough resolution

https://hobbycomponents.com/motor-drivers/755-pca9685-16ch-12bit-pwmservo-controller-module

couldn't get picture to copy, sorry. it would still need ouput buffers to drive 5v or 6v servos though.

The rest is basaed on my experience wth radar & electronic listening systems, not on detailed knowledge of the XS1278 loRa chip that I am using.
Receiver sensitivity is not really determined by absolute signal level but by the signal-noise ratio (SNR), where noise is either internal or external. If you cant increase the signal level then you have to reduce the noise by reduce bandwith (and bit rate), better front end transistors or by reducing the temperature of he receiver because the internal noise is limited by a physical limit depedant on physical temperature. Thats why satelite ground stations cool their recievers down and front end components sometimes have an equivalent 'noise temperature' quoted.
Whilst a packet sniffer helps to detect dropped packets it wont always give good guidance about sgnal reception based on its received signal strength. As an aside does your RF mdule not have a signal strength indicator of some kind? the SX1278 has RSSI (received signal strength indicator) that I intend to use to monitor the returned 'ack' message from the 'receiver' in the boat.
One of the aims of LoRa systems is to allow multiple users to share the same bandwidth, for us making a distinction between whats technically or regulatorary possible.
I don' know exactly how the LoRa works, its a company proprietary system but other systems work like this:
the basic digital modulation at a given bit rate is used to modulate a higher frequency pseudo-random bit stream, dividing each bit into multiple sub-bits sometimes called 'chips'. The user data effectively decides if the normal or inverted version of the pseduo-random chips are used. This chip stream is the key, it looks random but infact is predictable and repeats every so many cycles, often called a PRBS, and often generated with the shift register plus a bit of feedback logic. This obviously generates a much wider signal spectrum and the number of chips per bit I think is related to the 'spreading factor' talked about. This higher speed chip-rate modulation is used to modulate a normal FSK RF chain or similar. Note that one important point is that if you look at it usng a specrum analyser it will look like noise not a normal signal.
The clever bit is in the receiver. If you multiply (xor) the received chip stream with an identcal PRBS you will get a steady '1' (if the 2 chip streams are inverted) or '0' (if they are identical) for the entire bit period (N chips). If you then integrate over each bit perod you should end up with either N or 0. In reality you will end up with a value close to N or close to 0 so a simple level detect will let you determine if the bit is 1, 0 or if very bad a 'don't know'. This means that if another signal is in the same bandwidth unless it has identical PRBS it will cancel out to noise (because of the use of PRBS) but will degrade the integrated value a bit.
This is almost equivalent to a gain of 'N' and acounts for much of the increased sensitivty.
Frequency hopping (also in a pseudo random way) will add another level of immunity but probaby more importantly protects from channel fading which can be very frequency dependant at high frequencies.
The penaly is a more complex system and from our view point a much more accurate clock requirement to get everything synchronised. I noiced that the DRF1278 module I'm using has caveats about LoRa with low spreading factors due to their use of +/-10ppm xtal. That may not seem much but at 458MHz +/-10ppm equates to +/-4.58kHz so potentaly reduces our available channel width to a useable 20kHz to be guarenteed to be within the regulatory 25kHz. If you want narrower LoRa you need to use a better master clock frequency, a temperature compensated xtal oscilator that measures its own temperature and compensates for it.
What it provides when coupled with a robust message protocal (e.g. using acknowledge replies, message numbering to detect missing messages, error correcting/detection codes etc.) is a system that allows multiple users to share the spectrum, with a reasonable degree of confidence of getting the message through to the receiver. I think that is whey there is a 10% on-air limits to some of the 433MHz band, butI have not looked at he UK regulations for that.
End result with LoRa is yes, more spectrum usage, but the ability for multiple users to share with a reasonable quality of data reception.
I'm guessing the for us the loss of a few data packets is not too bad as long as the servo stays in the same postion (or reverts to a failsafe position if too many are lost), but all of this only works for a packet based system, the older 'analogue' PPM or PWM system would still fail and not be able to share spectrum.
The balancing act is what percentage of air time is required for each user versus how many want to share.
Any attempt to use he same RF channel as a backlink for telemetary would also casue sharing issues due to the additional data rate.
The regulations as I read it do not specifically state that any user can only use one channel, so in theory we could use LoRa and/or frequency channel hopping as long as we all use packet based protocols with collision detection or recovery (we probably dont need message sequence numbers since once we have a message we don't care about the previous ones) unless we try to send a complete set of servo position data using several message packets.
Thus I could see a technically feasible approcah being to have a smaller number of channel groups and each user declares which group they are using so that the available spectrum is shared out evenly with each channel group being limited to so many users. A bit like the old peg-board system for 27MHz that was used I believe.
I'm not usre how that would go down with the authorites mind you. The problem would be for aircraft where any possiblity of loosing control data for a signifcant period could be catastrophic so probably not acceptable any time soon.
There is aslo the issue of the older analogue PPM & PWM systems if any still exist on 458MHz, any new system would have to keep clear of their channels.

Anyway applogies if its toomuch waffle, and its back the arduino to get my FSK working!

Hi Simon,

A very interesting read - looks like you are making great progress - would love to know more about your work with "listening devices" but I am guessing it's possible you may not be a liberty to expand on that subject...

About 30 years ago I got seriously into using homebrew 23cms for communication so get the signal:noise challenges..

I have used the 16ch pwm boards before. Indeed I used one a week or so ago and at that point discovered something I did not know about them - they need to be calibrated on a board by board basis (and parameters updated in your code)

For that reason I have excluded their use from my project for now as whilst I can easily complete the calibration it would complicate my solution if others wanted to adopt it and use it in their subs.

I also bumped into an old friend "interrupt conflicts" - using the i2c library to communicate with the 16 ch pwm board and also the packet radio transceiver interrupts - so rather than get more grey hair I decided to accept defeat (unusual for me) and move on to another hardware configuration as I wanted to make progress in a sensible timescale.

As you know the 16ch PWM board runs by itself (independently from the Arduino) to drive the pwm output - this can be an issue if you lose comms with the Arduino. I have friend who launched his Tamar lifeboat out of the boating pond and across the tarmac when such a situation occurred - he ended up with a failsafe monitor just for the pwm board!

From memory you should be able to output the full range of pwm required by a servo in 4096 steps.

Thanks for the heads up re the packet sniffer - understand your concern. Already own the T shirt with that one. My RSSI readings both ways are included in the packet payload itself -so I am getting real performance info - the signal strength at the sniffer is irrelevant so long as I have a signal :)

I would love to say the next concept was invented by me - but is wasn't and to me was so obvious when I read it that I gave it a go....

The ACK back from the model to the shore is often a packet in itself. So I hijack the ACK packet and pack the payload with my telemetry data - 2 birds 1 stone

To date I have not found this addition to the ACK packet to be an unworkable Correction to original post  "workable" overhead but everything remains under review.

Are you writing your own comms protocol?

My next port of call with my project is "FailSafe Central" where I will indulge in some completely unnecessary whistles and bells

This is where I am at the moment



Regards
Jonathan _._

I was hoping to have had a basic RF link on 458MHz by now, but whilst the LoRa test prog was OK I am still strugglig with the FSK version. Various incarnations of libraries for the SX1278 but either it fails to configure or the range was rubbish, like the length of a desk!
I'm currenthly using the RadioLib library that is probably an overkill but it should work, but agai issues with the FSK. hardware seems oK as the LoRa mode works, but I think there are some timing issues with at least the 3.3V Arduino pro-mini, as adding the debug print options maskes it start to work, but not got a full link yet as I was talking to the designer.
I even looked at plan Z, design a 40MHz system, but whilst there are oodles of RF system on a chip none of them cover the 40MHz. I might try seeing if a chip going down to 70MHz could be persuaded to work at 40MHz, but I'll see what comes from RadioLib.
In the interim I might start looking at the various digitister modules to digitise the joystick pots, and bodge it using LoRa at 458 but hogging about 5 channels.
I also looked at replacing the 'low' spec oscilator chip on the DRF1278 module with a top spec deviice so I could use LoRa dwon to much narrow bandwidths, but I don't fancy trying to unsolder it to wire in another, not yet anyway!

not sure if this will add fuel to the fire or not....


the Raspberry Pi foundation announced this today:

https://www.raspberrypi.org/products/raspberry-pi-pico/


basically, its their competitor to the arduino, but is more like a teensy in its horsepower... all for $4

Is this the same thing or Arduino trying to keep up?

I guess this can only be good for the hobbyist with more options - even if not good for our grey matter:)

Arduino Nano RP2040 Connect

https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-the-world-of-microcontrollers/

C-3PO wrote:Is this the same thing or Arduino trying to keep up?

I guess this can only be good for the hobbyist with more options - even if not good for our grey matter:)

Arduino Nano RP2040 Connect

https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-the-world-of-microcontrollers/

yep, arduino has decided to embrace them rather than fight, and i think it is prudent. so many other providers of microprocessor boards have had to port on their own (stm32, teensy, adafruit, sparkfun), its interesting to see that arduino finds merit in doing it themselves. it should not be difficult, the device itself is an arm cortex m0 chip, and arduino themselves have arduino boards that use that same family of cpus...

my local electronics shop has the raspberry pi pico (100s of them) at an introductory price of $1.99... so, i had to get two of them... don't know when i will get around to playing with them, but i will let you know how it goes when i do... already know that raspberry pi themselves lets you set them up with either micro-python or c/c++ IDEs.

The inclusion of a 9-axis IMU should help to create inertial nav systems, if the core CPU can keep up!

SimonH wrote:The inclusion of a 9-axis IMU should help to create inertial nav systems, if the core CPU can keep up!

CPUs  - plural - two m0 32 bit arm processors running at 133mhz...  about 16x (or more - 32bit vs 8bit) the horsepower of an arduino nano.

Quite pleased I now have a functional master (transmitter) with two 2-axis joysticks. I use a 4 channel analogue input module to convert the analogue joystick voltage to 12-bit digital, follwoed by some simple scaling to generate 4 channels of 'servo' data each 1-byte. This seemed easier to me than getting a real transmitter and using the PPM test/simulate ouput. I might use a real transmitter in the future as the joysticks I have are the little ones and have no trim function. I might add that with another 4 channel input module and some pots and perform the trim digitally. I also want to add a digital input module provide the digital channels and specify the RF channel (curretly a default of channel 3 so I think I'm using channels 2, 3 & 4 due to the 62.5kHz bandwith with LoRa).
The Rx just displays the received values, so I have it all on a delay loop so it sends about 1 message every sec, so the next step is either a 16-channel PWM module or the S-bus modules, not sure which yet, so the Rx/slave actualy drives real servos.




not sure if Ive sorted out how to post images!

My take on the 458Mhz LoRa test project:

Thanks to C-3PO  for suggesting and providing  the improved ppm reader routine (This provides the significant benefit of only needing one Arduino at the TX, unlike earlier versions. Thanks Jonathan!) and thanks also to SimonH for suggesting a more suitable frequency and bandwidth.

The receiver end (This is already just about ready to go into a sub, virus permitting!):




The transmitter breadboard using a ppm feed from the trainer connection:



A video showing the gear working with failsafe:

https://youtu.be/fUb3OqYavnQ

The response is fairly slow, as I mention in the video, but probably OK for a marine model.

The range in air, even with the lower bandwidth, is very promising at 100m+.

The software (and all the hardware descriptions as "comments") are all freely available on Github:

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