Once encoded, there are plenty of ways to ensure error free transmission in as few bits as possible.

As long as you have more than one legitimate codeword, there is no way to ensure error-free transmission since there exists an error vector that will convert the transmitted codeword into another legitimately codeword that the receiver will accept.

I've done similar back in the 90s to essentially allow a nearly 1 Mbit transmission rate on a 115kbaud channel.

This depends on the data. There are plenty of data sources that allow extreme compression using even simple compression techniques provided the technique is designed for that type of data. But for every compression algorithm there exists data that, when compressed, will result in the compressed bitstream being longer than the original. The more random the data is, the less compression you can achieve and you can't get any meaningful compression on data that has been well encrypted prior to compression (if you can compress it prior to encryption, that a different matter, but that's not always possible, once again, it depends on the data).

 

If you are stuck with BCD, then you need to send 8 bits plus parity.
The simplest scheme I can think of is:
[START] [DATA] [CHECKSUM] [END]

a total of ten bytes.

 

Resolution is one second and will be transmitted, probably, once a minute. There will be one transmitter and multiple receivers. Each receiver can have a software RTC which can keep reasonably good between any error gaps. The source of the time is the MSF transmission and this goes off for maintenance for whole days from time to time.

 

The simplest scheme I can think of is:
[START] [DATA] [CHECKSUM] [END]

Post 23.

 

Resolution is one second and will be transmitted, probably, once a minute. There will be one transmitter and multiple receivers. Each receiver can have a software RTC which can keep reasonably good between any error gaps. The source of the time is the MSF transmission and this goes off for maintenance for whole days from time to time.

What is MSF transmission (not that it probably matters, just curious). Is it something like WWV or WWVB for transmitting standard time information?

If you only need a resolution of one second, why transmit the hundreds of a second? No real reason not to, I guess, unless you are trying to get max performance. But there is a risk, since if you use an error detection scheme, you risk discarding data in which the error is in the part of the data that you don't care about.

You have a pretty good error-detection scheme already handy. Compare the received time to the time that your RTC has been tracking and set a limit on how much drift is allowed (as a fraction of the time since the last accepted update). If it exceeds that drift, assume it was an error and discard it. If you can set the allowed drift small enough so that accepting an incorrect time that happens to result in an acceptable drift error until it is corrected on a subsequent transmission, life is good. You can strengthen this by retaining a rejected transmission and comparing both the RTC time and the rejected time to the next received transmission and acting accordingly.

 

You have a pretty good error-detection scheme already handy. Compare the received time to the time that your RTC has been tracking and set a limit on how much drift is allowed (as a fraction of the time since the last accepted update). If it exceeds that drift, assume it was an error and discard it. If you can set the allowed drift small enough so that accepting an incorrect time that happens to result in an acceptable drift error until it is corrected on a subsequent transmission, life is good. You can strengthen this by retaining a rejected transmission and comparing both the RTC time and the rejected time to the next received transmission and acting accordingly.

MSF is a time/date transmission from the National Physical Laboratory here in UK.
That method of checking validity had not occurred to me but it does seem very viable.

 

That method of checking validity had not occurred to me but it does seem very viable.

Now you can see why asking for help solving the actual problem (synchronizing time tracking in light of periodic, but unreliable, time updates) is much better than asking for help trying to solve some aspect of what you envision is a way to solve the problem (detecting errors in seven bytes of data transmitted wirelessly).

 

Nevertheless a CRC is THE gold standard for detecting transmission errors for decades, proven in billions of applications.

 

Naturally.

And as it's a link with errors, can we guarantee for ever that the last received was correct ?

 

If you are stuck with BCD, then you need to send 8 bits plus parity.
The simplest scheme I can think of is:
[START] [DATA] [CHECKSUM] [END]

a total of ten bytes.

That does mean having defined unique "start" and "end" data , so the data can be synchronised

 

The simplest scheme I can think of is:
[START] [DATA] [CHECKSUM] [END]

This raises another problem in my mind. I could choose start and end markers which should never occur in the data, but what if the checksum/CRC happens to match one of those markers how to surely determine the start and end of a packet?

Perhaps use a CRC7 which always has bit 0 clear and use '[' and ']' as start and end markers which have bit 0 set.
Would that work OK?

 

This raises another problem in my mind. I could choose start and end markers which should never occur in the data, but what if the checksum/CRC happens to match one of those markers how to surely determine the start and end of a packet?

Perhaps use a CRC7 which always has bit 0 clear and use '[' and ']' as start and end markers which have bit 0 set.
Would that work OK?

First up , yes , valid concern .
Second though , are you over thinking this ?
Do you know your error rate , do you know your data rate ? .
So for instance if your error rate is 1 in 10**12 , and your sending 10**3 bits per hour , that's quick mental calculation 1 error bit in 10**9 hours .
Check the numbers , im traveling so it's quick ball park , but I think you get the point .
You design the error protection to make your error rate what you want ..
Technically it's impossible to make a theoretical link zero error , . It's just how you want to cope with the error and what error rate you want
Have a good think. .
Just adding parity is easy , and adds to the reliability , adding CRC is fairly easy
There are other things like constantly spending dummy fixed packets when not sending real data , knowing roughly what the next data should be , so you can range check , etc. . .
The link can as you have seen be as complex as you like to achieve the error rate you want...
From what you have tokd us , I'd say a simple parity , with the bytes sent consecutively , and a known gap befire sending next group of bytes is fine.

 

If you must send two BCD digits per byte, can you send 9-bit data, i.e. 8-bits plus parity?

 

I want to send 7 bytes of data using HC12. If incorrect data is received then it is OK to wait for the next data. But it is important to be able to detect that the received data is correct as transmitted.

Microchip PIC and XC8.

What is the best method of doing this, please?

Hi A,
1st, Ive never been able to program well, but I received 2x Heltec V3 modules as a present.

I tried a couple of things, then tried AI, and simply asked AI to program them for me. If you ask for code to send from A to B module, it will write it then load the program with Arduino. It will then ask if you want the second one programmed, and you tell it that you want it to verify, that the data was received, and it will send "RECEIVED" back to A if the data was received.

Each has a lora radio and a screen.

I hope I've explained it well enough.
C

 

Hi A,
1st, Ive never been able to program well, but I received 2x Heltec V3 modules as a present.

I tried a couple of things, then tried AI, and simply asked AI to program them for me. If you ask for code to send from A to B module, it will write it then load the program with Arduino. It will then ask if you want the second one programmed, and you tell it that you want it to verify, that the data was received, and it will send "RECEIVED" back to A if the data was received.

Each has a lora radio and a screen.

I hope I've explained it well enough.
C

But that gets more complicated as I will have multiple receivers and so would need a system for deconfliction.

 

But that gets more complicated as I will have multiple receivers and so would need a system for deconfliction.

Hi A,
It does sound more complicated, but, I wouldn't find it difficult, where I used to.
Including multiple receivers.
C

 

? https://share.google/aimode/jfsTnKv4KQVMxJbjS the HC-12 thingy likely is more crucial here than your assumedly almost pin to pin length interface of XC8 and HC-12

an earlier search https://www.google.com/search?q=Microchip+PIC+and+XC8+common+serial+protocols+?HC-12

local res. : https://www.allaboutcircuits.com/pr...enting-the-hc-12-wireless-transceiver-module/

 

I used a couple of HC-12 for a similar data excercise.
Actually sending GPS data from a dog collar to a reciever.
** For maximum range, use FU3 mode at 2400bps. ** Edit*
BCD + CR/LF values sent once per second.
Time + date + location, so about 35 bytes in total.
The message length was fixed so 'decoding' at the receiver is simple.
I.E. You don't need separators. For your example. e.g. 0, 34, 12, 0, 6, 9, 26
Send it as 00341200060926

My final solution was to send the data three times. Each transmission included a header value of 01,02 or 03 as a message identifier. Then compared the 'important' parts of messages 01 and 02. If they agree, use the data. If they don't agree, compare each with message 03. Make a further decision.
(Your important part is all of it. I was more interested in the lat & long data, so ignored the time + date if they didn't agree).

So each message, always the same length:-
0100341200060926xy
0200341200060926xy
0300341200060926xy

Where x & y are values for CR & LF, used as message start identifiers.

Depending on the signal quality, there will always be some instances where none agree.
Your on your own there.....

Adding CRC is good for identifying a duff message, but no good for salvaging data.

 

I used a couple of HC-12 for a similar data excercise.
Actually sending GPS data from a dog collar to a reciever.
** For maximum range, use FU3 mode at 2400bps. ** Edit*
BCD + CR/LF values sent once per second.
Time + date + location, so about 35 bytes in total.
The message length was fixed so 'decoding' at the receiver is simple.
I.E. You don't need separators. For your example. e.g. 0, 34, 12, 0, 6, 9, 26
Send it as 00341200060926

My final solution was to send the data three times. Each transmission included a header value of 01,02 or 03 as a message identifier. Then compared the 'important' parts of messages 01 and 02. If they agree, use the data. If they don't agree, compare each with message 03. Make a further decision.
(Your important part is all of it. I was more interested in the lat & long data, so ignored the time + date if they didn't agree).

So each message, always the same length:-
0100341200060926xy
0200341200060926xy
0300341200060926xy

Where x & y are values for CR & LF, used as message start identifiers.

Depending on the signal quality, there will always be some instances where none agree.
Your on your own there.....

Adding CRC is good for identifying a duff message, but no good for salvaging data.

Do you have data on what the error rate and type of errors were?

 

Do you have data on what the error rate and type of errors were?

I've done some work using various radio signals.
In earth environment, Error rate is highly dependent upon signal level, but when errors do occure , they tend to be across multiple consecutive bits.