27Mhz - Radio Ideas

Yes,  our work on UHF systems a few months ago seemed like a doddle by comparison! (I have dropped back to a range of a few feet with the modules again! (Even installed in the sub but in air) Not worth taking a model sub to the water never mind diving it.)

Thanks for the tips for the software. I am working through the list.  (See TX version 3.1 and RX version 3.7) For some reason??? removing ALL the delays  in the TX stopped it  working - servo wobble etc. I seems to need a minimum of 5mS in the loop.

Later edit. I have been trying to increase the Buffer Size but the HardwareSerial.cpp file for my Nano seems to have no reference to memory size?

I am using the graph in the Radiometrix data sheet to calculate the RSSI from the output voltage.

I really need to get the range up again before this system is in any way workable.

Hi David,

So I eventually have the 2 Radiometrix modules wired up so I can begin to play.

Whilst I intend to try my own approach - which inevitiably will only be a twist building on your foundations I initially have 2 observations

1. I have increased long TX_interval = from 250 to 2500 (So I can hear/see clear packets whilst developing)

2. I note that your RX_PiN definition seems to have gone AWOL man.setupReceive(RX_PIN, MAN_300);

I am seeing a good data transfer so will start to experiment

Regards
Jonathan

* Note - need to switch TX frequecy - also review bandwidth which seems extreme!

Note sure what the glitch is yet re the arrow highlight in the picture

RSSI

Trying to get my head around this topic

The voltage readings I get on the RSSI pin is 0.8-0.9 with just noise - receiver enabled but transmitter disabled.

The Maximum voltage I get is 1.93v ish far short of 2.2v maximum indication.

More head scratching - I was under initial impression that you could vary TX power output - think it would be beneficial to measure power consumption of TX unit to see if it's near spec 100mA @ 100mW Transmit



Regards
Jonathan

A quick range check suggests that the transmitter is working well - so maybe RSSI of 1.92v is as good as it gets...

Audio suggests fully decodable signal @ 130m in air - (not line of sight - TX located inside house)

End stop signal on my trusty handheld scanner even through 500mm stone wall

So focus now switches to Radiometrix Receiver

Regards
Jonathan

Hi David,

I am about to start testing the data transfer integrity.

My testing approach consists of:

- Each data packet having a sequential packet ID - easy to test each time new packet arrives for missing packets
- Static packet data values will be checked upon receipt to check intact
- Received data values will then be cleared awaiting next packet refresh
- Some sort of CRC check added to packet

Will be interesting to see what this unveils. Assuming all well I will then ramp up the both packet frequency and data transfer rate

Regards
Jonathan

That looks very promising Jonathan. I have just measured the TX current also and it is 99 mA when transmitting. Any ideas on Failsafes? (see below.)

Just some reports on some model sub trials yesterday.

In brief, they were more successful and, I see this, as a green light for the project.

The improvements  really relate to the RX antenna used. I spoke with Nigel (who goes way back!!) and he said that he always puts the RX antenna in an insulated wire OUTSIDE the WTC. This may be an improvement because it also reduces the chances of interference from within the WTC.

The top two photos show the basic setup. The yellow wire antenna is attached to a short mast which also has an LED cluster which is triggered by stick input on  channel 2.





This gives an idea of the maximum range and you can see the typical vertical telescopic antenna:




This shows the RSSI plot from the data logger which was in the sub during the trial yesterday. Typical values are about -70dBm. I was hoping to use RSSI to trigger the failsafe but it doesn't seem very suitable. Noise?? Any one any ideas for  how a failsafe could be triggered? The commercial failsafes don't work because the  RX sends PWM pulses even when the TX is turned off. I certainly would not remove the tether unless I have some Failsafe.




This shows a dive (and surface!) :
https://youtu.be/0sf_fsIdLqk

This shows just general control and a typical range.
https://youtu.be/ymRCxNvoxag

Hi David,

Interesting update...

Failsafe trigger

I intend to approach this by resetting a timer after each new intact packet arrives

Intact = next Packet ID in sequence and CRC all good - or permutations of this.

If the timer reaches a Preset Value = no new packets /no new packets intact - trigger failsafe

Regards
Jonathan

PS Is Nigel, Nigel or John?

Hi David - re read you updates/exploits

Looks like my 1.9v 'ish on the RSSI pins agrees with your -70dBm. Presume you need to make a direct wire connection between TX & RX to get the quoted 2.2v :)

It might be worth experimenting with an RF front end preamp - ideally with a variable gain under Arduino control - (Bells, Whistles and cherry on top of the cake...)






Regards
Jonathan

Hi David,

I have spent more time looking under the hood of the Manchester library - slowly making sense of some of the code - I want a light bulb moment or 5

You are correct it does look like it has 5 states that it cycles through and does send "synch" bits, it also looks like it handles checksums

States
#define RX_MODE_PRE 0
#define RX_MODE_SYNC 1
#define RX_MODE_DATA 2
#define RX_MODE_MSG 3
#define RX_MODE_IDLE 4


I wish I understood more about bit manipulation rather than just the basics

Got to get more familiar with bit operators, however it not just the "what is it doing" - that needs to go very much hand in hand with "why is it doing this"...

https://www.tutorialspoint.com/arduino/arduino_bitwise_operators.htm

Code:

//encode 8 bit payload, 4 bit ID and 4 bit checksum into 16 bit
uint16_t Manchester::encodeMessage(uint8_t id, uint8_t data)
{
  uint8_t chsum = (id ^ data ^ (data >> 4) ^ 0b0011) & 0b1111; // Checksum what is the logic - frustrating
  uint16_t m = ((id) << 12) | (chsum << 8) | (data); // understand this line ok
  return m;
}

Regards
Jonathan

Very interesting. There IS a lot in that Manchester library.

I can't remember who first suggested it on here. (It certainly wasn't me. I had never heard of it.) But your Post No 67 (Mon 16 Jan 2023 - 22:06) includes the core concept of Manchester encoding - avoiding long strings of 1's or 0's)

That's the beauty of using Arduino there is so much developed software which you can just try for free.

And if Manchester is good enough for the Voyager spacecraft it may find a use in model submarines!

David

Probably not relevant but interesting

https://www.mitsubishielectric.com/en/about/rd/research/highlights/others/seaaerial.html

https://hackaday.com/2017/01/09/pumping-up-an-antenna-from-a-stream-of-sea-water/

https://spectrum.ieee.org/new-antenna-uses-saltwater-to-achieve-multiple-beamsteering-states

I got five minutes to play today

Pushed the baud rate to 2400 and the TX interval to 0.25 second - 100% solid copy and no lost packets

I will try these speeds with the TX & RX remote from each other @ weekend

I initially left the baud rate @ 300 and increased the packet transmission frequency to less then 1 second - this was unsuccessful.

There appears to be a "significant" overhead in the encoding/decoding with the Machester data - haven't got my head around this yet -you hear the audio of the transmission - there is then a significant delay before the packet data appears in the serial monitor @ the RX - this said the Manchester approach seems robust if you get timings setup correctly.

I think there are merits to getting the message delivered quickly - assuming propogation is favourable.

Once I have completed some evaluation of faster comms over distance I may experiement with including the  "baud rate" as a setting in the packet so it can be changed dynamically (remotely) to allow further evaulation

Regards
Jonathan

Listen below

SoundCloud

Everything was going well until!!!

I had set the first parameter of the packet to be a sequential packet ID - 0-255

I then noticed some corruption so I reduced the packet ID range from 0-11

What is going on with the packet ID highlighted in yellow - a consistent error...



Regards
Jonathan

That's interesting. I wonder if is losing "sync"? Does it need more delay between packets? (If that is how it works!)

Practically speaking, the latency between stick input and servo output is not too much of a problem for submarine models as long as it remains as fractions of a second?

The "overhead " problem seems to be part and parcel of the Manchester encoding system (See quote below,)

"https://www.allaboutcircuits.com/technical-articles/manchester-encoding-what-is-it-and-why-use-it/

The previous diagram also demonstrates a nontrivial disadvantage of Manchester encoding: the data rate is cut in half relative to the bandwidth of the data signal. A Manchester-encoded signal needs a transition for every bit, which means two Manchester logic states are used to convey one standard logic state. Thus, twice as much bandwidth is needed to transfer data at the same rate."

I wonder if Telemetry is completely out of the question? (I really appreciate seeing LiPo battery volts coming back via Telemetry with the openLRS and LoRa systems.)

David

Hi David,

I think you hit the nail on the head with regards to sync - I had come to the same conclusion'ish

This issue really intrigues me - my brain cells have been stimulated - I have a feeling of "here we go again" - unravelling an Arduino mystery.

I reduced speed back to 300 baud, tx interval every 2 seconds  - no difference - still corruption.

My gut reaction is that it's to do with the binary makeup of the first byte after the internal Manchester preamble. I will track down what the TX preamble is and how the RX identifies the start of data after the preamble.

I loaded the array with the following sequence 18,3,4,5,6,7 - all arrives intact where as 3,4,5,6,7,18 the first byte being a 3 nothing arrives at all.

It seems to work all ok if you pack the first byte with a value other than 3,4,5,6,7 - but that does not sit comfortably with me as a solution (yet)

I have spent hours inside Arduino libraries and still find the structures, cross referencing very confusing to follow.

In the past I have pulled the code out of a library back into a sketch where all of a sudden I can see exactly what is happening - I think I will attempt to do this for the Manchester library.

Watch this space

Regards
Jonathan

Think I lost a few more brain cells today to this problem.

It looks like the Manchester preamble is three 1's to mark start and three 0's to mark end of message.

So I have just taken another approach and used packet id's 11-20 - at least I can check for sequential packets - this seems to work well

So I got bored of the heavy One and Zero hunt and decided to play - the result my shiny new S Meter :)

The other led strip is pulsing indicating packet activity - I am going to use another couple of LEDS to show sequential packet status and CRC status

I am using a second Nano as the "monitor" driver leaving the main Nano to play at catching packets in a timely manner

Regards
Jonathan

you probably already know, but just in case...
Strictly the manchester encoding is simply a way of encoding bits in a data stream, so that each 'bit' has either a 0 to 1 or 1 to 0 transition in the middle. This allows it to provide its own clock.
The next bit is to add a preamble of all 1 or all 0, this generates a square wave that alows the receiver to lock on its own clock, so in theory the receiver doesnt have to know the exact bit rate.
The length of preamble is not fixed, but I've worked on systems that used 5 or more, a longer preamble also allows for any AGC to kick in.
I would also expect a 'start' bit just as in RS232 type comms, since if AGC is involved you can't guarantee that the first few bits have been received correctly, so you need a start bit to indicate the end of the preamble, not just count the bits.
If you look at the wikipedia entry for manchester encoding there are also 2 versions of manchester, just to add confusion.
The logic for encoding/decoding is not complex, so you might find it easier to write your own, there are many examples of that on the web.
I must admit my pet hate at work is trying to understand someone elses code.... they always seem to do it wrong!!! :)

Hi Simon,

I think you suggested Manchester encoding in the first place? If so many  thanks!  The good thing about it is that the Arduino version seems to work pretty well "straight out of the box".

You have given a very clear explanation above. I now understand that the "Preamble" also sets the clock amongst other things.

I quote the rather less clear Radiometrix guide below: (The links in the article don't work.)

"Your data over a simple radio link" By Myk Dormer - Senior RF design engineer, Radiometrix
First published in Electronics World magazine. March 2007 issue
Application note 028
A practical realisation:
It is possible to still use a hardware UART (rs232 type asynchronous interface) and fulfil all the requirements of the link, if
a little care is taken.
The data is sent in a burst, or packet, comprising of:
[preamble] [uart ‘start’ byte] [framing bytes] [data ‘payload’] [checksum]
Characters must be sent continuously, start bit to stop bit without gaps (or the mark:space ratio will become unpredictable)
Assuming 1+8+1 (one start, 8 data, 1 stop) format, a sequence of 55h (ascii U) characters provides a square wave
preamble. After the transmitter is turned on, a stream of these preamble bytes must be sent, until the ‘tx-on’ time spec. of
the radio module used has been met. (This will usually be between 3 and 50mS, depending on the module)
An FFh byte must immediately follow the preamble, so the UART can frame on an identifiable start bit. To maintain DC
balance, a 00h byte must follow the FFh. Both these bytes can form part of the decoded ‘framing’ sequence of the burst.
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)
It is necessary to use a number of fixed value bytes preceding the actual data ‘payload’ as packet identification (or
‘framing’ ), to allow the decoder to tell a valid data burst from random channel noise. (In my experience, to avoid false
triggering of the decoder, at lease 3-4 bytes of framing data will be necessary.)
Additionally, one or more ‘address’ bytes may be added (to allow co-located operation of multiple systems, or polled
access of multiple receivers by a single transmitter), and ideally, a checksum of some kind should be added to the data
packet, as an extra precaution against spurious triggering.
I have described a very simple protocol here. There are many, far more sophisticated techniques in use throughout the
industry. The method described does not even offer the best in S/N performance (as the edge triggered UART receiver is
overly susceptible to data bit jitter and dropouts compared to a proper duration measuring biphase decoder) but it shows a
workable technique, with a minimum of software effort and processing overheads.
Sometimes a simple approach is sufficient.

Hi Simon,

Yes I have just got upto speed with the information you posted - good to read validation of my understanding.

Interestingly - the manchester library code by Mchr3k suggests that they use 14 One's or Zero's for 433mhz comms link to get the stabilisation of the agc

https://github.com/mchr3k/arduino-libs-manchester

The preable / terminator is a setting within that library

Code:


//define to use 1 or 0 to sync
// when using 1 to sync, sending SYNC_PULSE_DEF 1's , and send a 0 to start data.
//                       and end the transimitting by three 1's
// when using 0 to sync, sending SYNC_PULSE_DEF 0's , and send a 1 to start data.
//    



Code:



The 433.92 Mhz receivers have AGC, if no signal is present the gain will be set to its highest level.

In this condition it will switch high to low at random intervals due to input noise.

A CRO connected to the data line looks like 433.92 is full of transmissions.

Any ASK transmission method must first sent a capture signal of 101010........

When the receiver has adjusted its AGC to the required level for the transmisssion

the actual data transmission can occur.

We send 14 0's 1010... It takes 1 to 3 10's for the receiver to adjust to the transmit level.

The receiver waits until we have at least 10 10's and then a start pulse 01.

The receiver is then operating correctly and we have locked onto the transmission.

I have been tempted to explore some of the Amateur Radio digital protocols - especially those designed to opeate on signals below the noise threshold - but they are SLOW DATA RATES (no suprise).

Regards
Jonathan

I have had this idea spinning around in my head and can see both pros and cons - any opinions /suggestions

I think it's imperative to use a checksum to validate the data or this concept will suffer from "garbage in - garbage out"

Option One : If the packet contain 8 bytes and the checksum is invalid then you have no choice but to ditch the complete packet wasting 64 bits of packet data and associated transmisson / unpacking overhead

Option Two: If the packet contains a single byte and is invalid you only waste 8 bits of transmission time - I realise preamble header and message terminator frequency would add a little to this method

So with the probability of dropped packets due to low signal what do you think is best?

Regards
Jonathan

From what i remember from openlrs, kha tried forward error correction for single bit errors but there was rarely just a single bit so if it failed the checksum it was usually unrecoverable. With an rc system were updating the same data repeatedly so its not critical if a packet or few go missing as they the values will just get updated with the next available valid packet.

Just a general point. R/C systems seem very tolerant of lost or corrupted data. There is always another packet coming along soon!?

I was reminded, this Sunday, how tolerant model submarines are (as opposed to planes)  sailing my CSS Pioneer model using the LoRa setup on 458 MHz . This only sends data about every second but the model is still very controllable and it is reasonably fast and small.

This screenshot shows the Lora trace:










Sorry this has rather gone off the 27MHz topic. Coming back, has anyone had any experience of using a Vector Network Analyser (VNA) for optimising antenna?

first a few thoughts on noise and errors....
There are unumerable schemes for error correction & error detection, the two functions are not quite the same, but they depend as ever on the details of the communication & the link. For simple repeated stuff like a servo position the important thing is to detect the errors so the data can be discarded, as pointed out there is another command comming along soon so no problem. Video similarly could be discarded ubtill the next frame. Message based system on the other hand have to have error correction, or some kind of back haul protocol to request a re-transmission but then you have have messsage numbers so you know which to repeat so it gets complicated.
The other factor is the noise/error characteristics. If the errors are caused by noise (or rather signal to noise ratio) then you can get some interresting effects; analogue FM is quite tolerant on noise, as the signal gets weaker the audio degrades but is still useable, DAB on the other hand will cut out sudenly as its error rate is very non-linear.
Generally the more additional bits you add the better the code is at detecting/correcting errrors. E.g. the simple parity check will detect a single bit error, but may not detect multiple bit errors, nor will it give any error correction, so is not much use with error prone signals.

Loads of work was done with magnetic disk systems in the early days, but now used in flash memories etc. so ride on them! good codes to start with are are Reed-Solomon or Hamming codes, both are based on a fixed length block of data to which extra bits are added. Don't make the block too long as it increases the latency as the whole block has to be processed before the entire block can be released.
Again try wiki or other sites for more info.

I have used vector analysers to tune systems, but it requires more than the analyser itself. There are various versions but all rely on the idea of comparing the antenna impedance with a known reference.
One way is using a VSWR bridge that injects the test signal into the test item and the reflected power is then picked out and fed to the input of a receiver to measure. Obviously if the antenna is matched then the maximum power is transmitted into the 'ether' and minimum power is reflected back. This is all based on directional coupling of signals but you should be able to find details of 27MHz ish VSWR bridge from radio ham books.

The other way is to use the capabilities of the vector analyser more and set up a wheatstone bridge type circuit, one arm is the test item, the other is a reference and the I & Q inputs are across these points
If you had a bridge of 3 x 50ohms then if the antenna is 50ohms the I & Q inputs would be identical, so no phase difference or amplitude difference.

The problem is the practical issue of making a VSWR bridge or balance bridge that is sufficiently balanced to be able to measure to the sensitivity required, again some radio ham books should help.

Many years ago I tride to create a 458MHz radio control but I never got the antenna sorted, but being UHF it was by cutting bits off untill you go too far when you try to stick it back. 27MHz should be easier as you can probably use variable L & C to match.
I never understood antennas, smoke and mirrors if you ask me!

david f wrote:
I was reminded, this Sunday, how tolerant model submarines are (as opposed to planes)  sailing my CSS Pioneer model using the LoRa setup on 458 MHz . This only sends data about every second but the model is still very controllable and it is reasonably fast and small.

Auxiliary functions are even more tolerant of latency so you wouldnt need to update all of your channels with every packet. The higher channels could be sent sequentially rather than all together to save bandwidth so each packet would contain 1234+5, 1234+6, 1234+7 etc, so your main controls have the lowest latency but you can have essentially unlimited number of channels, the only downside is the more aux channels you run the more latency increases for them. im sure ELRS does something similar so they can run the primary channels at very high speeds, like 400hz.


Even if we are only sending a transmission every 250ms with 8 channels, the upper 4 would have a latency of about 1 second and an extra second for every 4 channels you add, so 2 seconds for 12 channels and 3 seconds for 16 channels.

yes... ExpressLRS will only send the first 5 channels of data every packet, additional packets are required to send channels 6-12. number of packets required to do that depend on which version of expresslrs you are using, and which "settings" you are using... basically if all of 6-12 are on/off switches, they can all be updated in a single secondary packet... if all of 6-12 are proportional channels, it will take six secondary packets to send the data.