27Mhz - Radio Ideas

Hi David,

I will read your thread and code in more detail to come up to speed with your topic.

It does look like you will have to negotiate a tightrope with these modules. I think you will need to create your own packet protocol.

I would go back to grass root basics and construct a hard coded message, remove all code not associated with basic message delivery, and work on receiving that successfully and then work back up to the whistles and bells.

Code:


E.g.
//preamble - send preamble 0x51 for minimum of 30ms
starttime = millis();
endtime = starttime;
While ((endtime - starttime) <=40) // do this loop for min 30mS
{
Serial.write(0x51);
endtime = millis();
}


Serial.write(0xFF); // FF start framing bit
Serial.write(0x00); //

byte message[] = {0x93, 0x95, 0x8E, 0x8E, 0x99 }; // msg=SUNNY
Serial.write(message, 5));



A couple of initial observations

- Have you initialised the modules? Are they on the same channel/frequency?

- Have you spotted that you can only TX a subset of 66 useable values. Values from 0-255 where the binary equivalent has a balanced number of 1's and 0's (4 of each)

- I see you send the preamble of 55h 6 times - does the meet the required duration of 30ms from TXE transition

- You cannot use message start  0x21 ascii ! (b100001) or messager end 0x23  ascii # (b100011) - see valid 60 binary patterns (4 zero's and 4 one's)


I spotted several other things but cannot recall them now as I type this - will update you later


I am tempted to buy a couple of units... I have a call out for them to ring me back...


Update: - Have you seen the Radiometrix Narrow band Evaluation Kit (NBEK) IC. Looks like this is a chip that handles the preamble & framing - from what I can see you can use one both ends and then you end up with a traditional 1200 Baud Modem radio link that you can plug into. Not sure this is compatible with 4kbps LMT0 as it states > >5kbps data rate. I guess a call to the Radiometrix mothership would confirm ...

http://www.radiometrix.com/content/nbek-ic

I have scanned the net and not found any code Arduino code examples or libraries that have been written for this module - maybe Radiometrix have a code shell - looks likely when you read the PDF file "Your data over a simple radio link" as it has everything apart from the code :(

http://www.radiometrix.com/files/additional/your-data-over-a-simple-radio-link.pdf


Regards
Jonathan

Lucky 66 :) - binary codes with "balanced" 4 x Zero & 4 x One digits

Extract from Your data over a simple radio link

Then, to maintain mark:space balance, data can be sent by using only those characters with an equal number of ones and zeros in them.

Of the 256 possible 8 bit codes, 70 contain 4 ones & 4 zeros.

Omitting 0Fh, F0h, 3Ch and C3h (worst case ‘four ones in a row’ bit sequences) still leaves 66 usable codes per byte, which allows six bits of actual data to be coded into each transmitted byte.

(A full explanation of this method can be found here: http://www.radiometrix.co.uk/products/bimsheet.htm#rs232) - invalid URL

Thanks for all the very useful suggestions C-3PO and geofrancis!
Working through them in time order:

I have again tried sending direct ppm data through and it now works! Thanks!
I had the data voltage level at the TX too low.

This shows the trace at the RX data output (range about 30 feet indoors- too cold to head into the village!) and it looks like a perfectly respectable ppm stream to me.



This tells me a lot:

- The modules can send data.
- It may provide a very simple setup for 27 MHz r/c .

On to the other suggestions - it would be good to go digital.

David

* The ppm stream measured at the TX for reference.

Hi David,

That looks very encouraging.

If you plug the received ppm stream into a decoder I wonder what the individual channel values are compared to the original ppm stream?

It will also be interesting to see if there is any jitter...

Regards
Jonathan

Thanks Jonathan. No sooner said than done!

https://youtu.be/M31LBSBRkPw

Geofrancis suggestion works well on the bench and it is so simple. Just the RX module and an old friend the JHMCU convertor.

Wiring chaos is down to temporary removal of Arduino. I will now move onto trying your suggestions.

David

Still a bit puzzled why I am unable to transmit the digital data. (i am not very knowledgeable about sending serial data)

Using  a twin trace (TX and RX) on the scope (RX is the red trace) starts to give clues.

This is the direct ppm stream. A pretty exact copy.




This is a simplified digital stream the software is on:

https://github.com/rdforrest/27MHz--Radiometrix-module



Not an exact copy by any means but has got much "cleaner" over the last few days. I have given the TX module a separate 5 volt supply rather than tap off the Arduino.

Just curious what happens when you disconnect the ppm signal to emulate loss of RC, does the pwm outputs from the ppm decoder stop or do they hold the last PWM value? If it stops then that will work as a motor failsafe and any ESC connected should shut off immediately. For servos they will essentially hold position if the signal just stops so in order to have a functioning failsafe you would just need to add a nitro engine failsafe device to whatever channels you need to move when it fail safes, this basically just sets the servo to a preset position when there is a loss of signal. so for a sub you need one for the ballast tank and possibly the dive planes.

https://www.ebay.co.uk/itm/401482463111

Interesting question. I will connect the decoder again and report back tomorrow.

Well I have actually got the modules to send digital data. It is all a bit wobbly and on only one channel but you have to start somewhere. Range about 1 metre!

This shows the TX (top) and RX streams displayed with the, much clearer, Picoscope Version 7 software (just updated it).



(95 is the stick position data in hex.)


https://www.youtube.com/shorts/0n0mM4qhMKs?

RX 2.7 & TX 2.6 versions of the software on:

https://github.com/rdforrest/27MHz--Radiometrix-module

Yes, i can confirm that with the direct ppm setup the servos simply freeze when the TX is turned off i.e no failsafe. (The failsafes you indicate look pretty nifty. My only worry may be that "pressing a little button"  on the unit may be difficult to do on a submarine! Hopefully it saves the value even on power-off.)

I am still puzzled by how much better the direct ppm setup seems to work than the digital setup???

I have still only got the digital version to work on one channel with a wobbly servo on the bench. (Though I am not very expert on WiFi software!)

The direct ppm version is now working on the bench with 3 (very steady) servos.

I think I may go on to range testing the direct ppm version.

The ultimate goal is to try it out in a model sub. (Once the ice thaws!)

And then try immersed antenna (much smaller) with help from Rob in Holland.

David

Hi David,

Interested to see your journey progressing.

Radiometrix sell a - RF modem chip – for Narrow Band FM wireless data link

M48A-000-DIL @£9.75 each ex  VAT (you would need a pair)

http://www.radiometrix.com/content/m48a

Datasheet
http://www.radiometrix.com/files/additional/m48a.pdf

This does all the protocol handling, message heading, hand shaking, preamble etc

The M48A is a half-duplex serial modem controller suitable for use with narrow band receivers, transmitters and transceivers.
It supports a maximum transparent data throughput of 4800baud while baseband modulation frequencies do not exceed 3.2KHz
The device supports (programmable) long startup/preamble durations sometimes required for synthesized narrow band devices.

I love the word transparent - if you take them at their word you simply squirt serial data in @TX and catch serial data out @RX :)

Regards
Jonathan

david f wrote:Yes, i can confirm that with the direct ppm setup the servos simply freeze when the TX is turned off i.e no failsafe. (The failsafes you indicate look pretty nifty. My only worry may be that "pressing a little button"  on the unit may be difficult to do on a submarine! Hopefully it saves the value even on power-off.)

the failsafe devices should only need set once and should hold that value, they are originally designed to cut off nitro engines on rc cars since regular 27mhz and 40mhz systems work exactly the same as your test setup, cutting off pwm when signal is lost.

I have just been range testing the 27Mhz direct ppm version and it performs well - past the church in our village, so 100m+.  I think it may just make it to the pond at Barrow for a submerged test.

(Antennas used are flexible wire dipoles, 2m long so could be better!)

David

31st Jan - Later edit

The 2 fail safes arrived today and they are working fine. I can confirm that they DO hold their value after power off.

NICE! your probably the owner of the first new 27mhz RC system with more than 4 channels since the 80s.

once you get a digital version working the biggest advantage it would have is interference rejection, because it would be bound and each packet would have an identifier so if its not addressed to the receiver it would just ignore it. even if someone switched on another old 27mhz transmitter on the same channel near you it should just reduce your range but you should still keep some control. that's the main weakness of the analogue system is it cannot reject interference, so it shows up as erratic servo movement.

NICE! your probably the owner of the first new 27mhz RC system with more than 4 channels since the 80s.

Yes! I hope this is not an exercise in creative nostalgia!

I tried out some underwater trials yesterday and it seems to work well and better than I expected.

This is the prototype TX and RX. Really very simple and practical (Not too much soldering). Note the dip switches to change frequency. The antenna for both was a a stiff wire dipole, 2 m total length. To fit in the tube for the RX the wire was loosely  wound around the dowel which formed a chassis. The antenna was later cut shorter - see later comments on range.



The basic setup, same as the LoRa trials really. A float supports the tube which is suspended about 0.5m below. The float has a cluster of bright LEDs which are switched by the rudder stick on the TX.





The float moored by the side of the lake. (Note healthy milk bottle rather than bad tonic water bottles in LoRa trials! Lockdown!)



The map of the lake showing the range which was at least 50m transmitting down to 0.5m. (Points 2 to 6)
The cut down antenna gave about half this range.



The surprise was how well the crude antenna functioned.
The next step will be to try it out in a working submarine. (Fail safes on order - thanks!) Interference from drive motors etc. may be a new problem.
I will continue work on the digital version also - this has to be the way to go, as you say.

One useful feature of the RX is that it has an audio output. The first thing I did when I arrived was plug an amplifier and earpiece in  and click through the 6 frequencies to check for interference. Nothing. No " Breakers" in Barrow!

What the range looks like. You wouldn't want to control a sub at more than this. My thanks to the lonely figure on the shore - Adrian who worked as an "LED repeater". (I couldn't see them at that range.) (Adrian tells me that he has a very old 27Mhz setup in his garage - 4 channel!)


Jonathan - Thank you very much for the notes on the M48A. I will try to get software working first - to save space and possibly cost.

excellent work on all these different tests of the differing technologies.

Very kind words, Tim. Thank you for "setting the ball running."

David

The results of the latest 27MHz trial - not very successful. A setback! I should have tested the range of the model in air before I travelled to the pond.

The idea was to get the Radiometrix  (direct ppm) system to control a (tethered) model submarine.

The transmitter and model. Note the horizontal dipole on the TX. Probably about as efficient as you can get but not very practical. I had to be careful not to knock my model boating chums into the water!



The model - CSS Pioneer as it happens.




The maximum range of about 10 feet. Very poor but the model submerged and surfaced at that range. I didn't notice any interference effects from the brushed drive motor.



The receiver end. A "scrunched up " antenna in time honoured submarine fashion!



LATER WORK:

I have just been trying the assembled model in air at home. It had the same very poor range of about 10 feet. I opened the model and unwound the antenna wire a bit outside the model and a practical range (10m +) came back.

CONCLUSIONS:
It looks very much as if the receiver antenna needs much more attention.
Does anyone have any ideas how it could be made more efficient in the close confines of a model submarine?
It does emphasize the potential for developing an immersed antennae. Potentially 1/10th of the length in air.

a few things to consider regarding the receiver antenna:

1) use one of the online calculators to figure out what a 1/16 wave antenna would be

2) make a loaded antenna like the vintage helicopters used to use

3) make a much nicer loom for your current antenna, like the r/c car guys did in the 90s, do not overlap the wire...


I am trying to find photos of #2 & #3, but the internet seems to have forgotten all about the vintage stuff.

Hi David,


My head hurts - can't remember the theory - don't think 1/16th wave length will be easy to use -  me thinks impedance becomes capacitive, radiation/reception pattern will change and if I am wrong on those two I am right on the impedance going loopy - the mistmatch will kill performance without matching device


David - could you connect your SDR dongle to the "antenna on trial" in the sub as you experiment - might give you some more scientific measurement of signal strength etc

Most antenna theory is for the elements in open air "free space" and not close to another object - so the antenna proximity to other parts of the sub is likely to impact on resonance...

Regards
Jonathan

Rather more success yesterday.
This photo shows the, quite adequate,  range to the RX in the test float at a depth of about 0.5m.
The improvement  relates to antenna improvements. I have been doing more range tests and also using the RSSI on the RX.




Interestingly a standard vertical telescopic TX antenna gave better performance than my earlier horizontal dipole and it is much more practical.
The RX antenna is stiff wire but with a loading coil inserted, which I had left over from somewhere.



Interestingly also this trial was using the first digital version of the software. I don't think that the earlier direct ppm version would necessarily give less range but digital looks like the way to develop.

The software uses Manchester encoding (If it is good enough for Voyager 1 & 2 it is good enough for us and it was originally suggested in this thread !)  at a very low data rate (300 Baud but I will try to speed this up. The servo shows slight but workable latency.) but it is only for 1 channel so far. Manchester encoding seems to be easy to implement on the Arduino.

(TX version 2.9 and above and RX version 3.2 and above at:

https://github.com/rdforrest/27MHz--Radiometrix-module

)

The next step will be get a 6 channel version back into a model sub and see how well that does. Then start looking at the underwater RX antenna.

Later edit: John Robinson phoned me yesterday for a chat and some suggestions about antenna impedance matching.  He reminded me that he did some early trials using underwater antenna back in 2012. The details are here:

https://www.theassociationofmodelsubmariners.com/t897-high-power-rf-amp-for-low-frequency

finally found a site that shows #3 on my list above:

https://www.darrolcady.com/Racing_Info/Tips-tech/Antenna.htm

Second attempt to use the Radiometrix modules in a model sub. (My model of E11 tethered for safety.)  This time using the 6 channel digital version. (Software TX Version 3.0 and RX Version 3.6)

https://github.com/rdforrest/27MHz--Radiometrix-module

But still very short range - the photo below sums it up:



The only positive news was that it did enable the sub to do a dive and it DID get the surface signal too. (See the video link below.)

https://youtu.be/xBs-mxvQCQs


The model was carrying an SD card data logger to record RSSI every 30 seconds . (Unfortunately the Real Time Clock backup battery had died - so no actual date/  hour of day  record.)

The screenshot of the spreadsheet shows some of the data and the graph. It is slightly puzzling because it shows that the RSSI stayed at what I thought would be a "good" value of about -70 dBm? Does RSSI not show the whole story of successfully sending data?



Still more work needed on getting a good RX antenna. Thanks for the info, Tim. Nigel tells me that back in the "good old" days of 27MHz that the aerial wire was usually positioned outside the WTC (yes in water!) and wound on a "comb" arrangement.
Still way to go on this, I think.

The only thing I can think is that the digital signal needs a cleaner signal to work where as the analogue signal can be picked out at much lower level. Similar to analogue tv vs digital tv where its an all or nothing with digital tv, whereas you can still see a fuzzy image even with a coat hanger on the old analogue tv.

Hi David,

How are you calculating your RSSI figure?

Are you getting approx 0.2 - 2.2v when you read the RSSI pin with the Arduino before any calculations?


My experience with serial comms when the two devices are not directly "hardwire" connected you have to adopt a different approach.

We tend to think we can keep adding functionality (whistles and bells) to our projects and in the main the good old Arduino will cope and indeed they often do.

I bumped into a performance/timing/sychronisation issue when driving multiple steppers. I ended up distributing the processing across a network of Nano's all talking to each other via i2c.

The other thing I discovered is how slow the Serial.print() command is and can easily choke the program flow

To get a real understanding of what is going on - I would focus on one Nano being the core message receiver/handler and move all functions to another Nano. The 2nd Nano gains access to the received data by using i2c comms, can do all your serial debugging prints and also can monitor the RSSI pin and write data to the SD card.

Another additional benefit is that you could then use the onboard "proper" serial port of the main Nano to connect to the receiver and not the pseudo software serial port as it's possible that the software serial may under the bonnet have some limitations and it's another overhead you can do away with (no need for software serial library etc)

In the short term I would also forget the actual model control aspect - I would have a test script of values that I transmit and then if you adopt this approach you could also write each packed received along with RSSI info to the SD card - an Excel comparision after the event of TX data and RX data from SD card will no doubt be illuminating.

Suggestions
> Adopt an approach where the live version of your code does not contain any(as few as possibe) active Serial.print commands - most of which we use for debugging - adopt an approach where you can toggle on/off serial printing

See https://forum.arduino.cc/t/toggling-debug-code/47041

> Review/remove any delay() commands - why are you stopping the processor from doing anything? - you may be loosing incoming serial data

> Amend the Serial buffer size
https://www.hobbytronics.co.uk/arduino-serial-buffer-size

I know you are using hardware serial so see this article
https://arduino.stackexchange.com/questions/1726/how-does-the-arduino-handle-serial-buffer-overflow

> Don't send more data until you are certain that the receiver has proccessed the last lot - whilst developing increase the transmission gap between each packet

Some of my later suggestion conflict/irrelevtant (e.g. debug printing) with the initial text but I think you get the idea...

Just my tuppence - Loads more ideas - but work beckons :(

Regards
Jonathan

Hi David ,

More thoughts...I have looked at your code on Github.

The transmission frequency of data definatley needs to be throttled back as currently transmitted approx every 15ms or so (60 plus times a second)

I would have thought 4 times a second would be ample - (TX_interval =250)

Easy way to do this would be to add a timer so you can trigger the TX code on a preset interval

Code:

long TX_previousMillis = 0; // last time updated
long TX_interval = 250; // interval - our delay interval in milliseconds


void setup()
{
}


void loop()
{
  unsigned long currentMillis = millis();
  
  if (currentMillis - TX_previousMillis > TX_interval)
  {
       // time TX_interval has been reached - run code here

      man.transmitArray(datalength, data);
      moo = ++moo % 2;
      digitalWrite(LED_PIN, moo);
      
    TX_previousMillis = currentMillis; // update the time we have run this event so we can compare with future time
  }
}

Interrupts
Not quite sure how you have TX sticks connected to this project - and also not sure if you are using interrupts to read pwm

I think this area needs thought. If the interrupt is triggered to read the pwm channels

What happens if you are half way through transmitting serial data and the interrupt is triggered - the interrupt will do it's stuff and then pass the processing back to the loop.

In the meantime the radio TX will have been left in one state of transmitting a constant tone so the frame will have been corrupted.

Food for thought here...

Regards
Jonathan

Playing around with the Radiometrix units - they remind me of using RTTY 45 years ago.

The preamble sounds just like the "mark/space" of a RTTY transmission

https://youtu.be/0AwnMe-CSJs?t=214

Regards
Jonathan