Go Down

Topic: Serial Input Basics: example 5, question (Read 2217 times) previous topic - next topic

Deva_Rishi

The wire.h is used in the original program to accomodate use of I2C
Well while we are not using it, comment it out

How would you suggest to improve this?
at the very least let's send information about how often this situation occurs to the Serial for now.

Quote
Question 1: the appearance of < in the message x+1 still puzzles me. Is there any possible explanation?
The explanation that somehow there may be overlapping messages, due to an endmarker not being received.
Quote
During the 6 hours the test currently runs one crash occured:

actual message: 4 1 . 6 7 , 2 βΈ® 0 , 2 , A .

ASCII message: 52 49 46 54 55 44 50 255 48 44 50 44 65 46 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
255 ?? that was never sent, your transmission-reception is corrupted ! I want to know your complete hardware setup. How long are your cables how are they powered and how are they shielded ? I was going from the point of view that you had it in a 'lab' setup using the low BAUD-rate but not depending on it, but now i am no longer sure. If the bits being received are not the same as the ones being sent then all the other work and suggestions are pointless other than for educational purpose.
To 'Correct' you have to be Correct. (and not be condescending..)

Robin2

As far as I can see whatever is the problem it is not a fault with my Serial Input Basics

There are too many cooks paddling around in this soup so I'm gonna drop out.

Just one last thought ... any time I have found myself with a significant programming problem the solution has ALWAYS involved making things simpler and shorter.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

brice3010

As far as I can see whatever is the problem it is not a fault with my Serial Input Basics

There are too many cooks paddling around in this soup so I'm gonna drop out.

Just one last thought ... any time I have found myself with a significant programming problem the solution has ALWAYS involved making things simpler and shorter.

...R
I am sorry to read this but I understand. Sad because this is not of my making. Can you please give your input how to program the calculated XOR at transmission and at reception?

Whandall

Can you please give your input how to program the calculated XOR at transmission and at reception?
Is Google down?

If it comes up again you could try https://www.google.com/search?q=xor+checksum+example+c%2B%2B

Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Deva_Rishi

#79
Jan 21, 2019, 10:36 pm Last Edit: Jan 21, 2019, 10:43 pm by Deva_Rishi
I talked about manually parsing the data before, and well sometimes it is time to put your time where your mouth is, and so here with the inclusion of Robin's data reception i came up with this bit of code which will just invalidate any input that was not within it's parameters (and not using strtok() )
Quote
Code in attachment due to 9000 chars limit
I also included the hexvalue, that you wanted in your most recent post, so by now there are 7 data pieces, it is more for educational purpose, since as far as i know you will get to working version without it, which brings me to this
Quote
The baud rate used is 1200: this allows the maximum possible range for the HC12 radio.
If you want to run a long line and because of that you drop down the BAUD-rate that far you should really look at improving the hardware. I suggest one of two options, My choice would be to make use of max485 standard, where by means of 2 transcievers (per direction of transmission) and a twisted wire you can cover distance of up to 300m at 250kbps

Or to transmit using the same hardware specs as DALI uses and transmit and receive using Manchester, which is also just as slow at 1200 bps, but since it doesn't depend on a clock and is a lot less sensitive to sync issues then normal serial. Like that you would also be able to cover up to 150m. The second option is more complex to program and therefore i suggest the first  and since you only have data going 1 way a few parts and a UTP cable will do the trick and will provide reliable transmission.
To 'Correct' you have to be Correct. (and not be condescending..)

brice3010

Hi Deva_Rishe, thank you for your input.
However, in my setup communication takes place wirelessly with HC-12 433MHz radios: up to four transmitters, one receiver.
So far my tests have shown that the issue with crashing at the receiver most likely occurs because an invalid character did enter the sent data (or the very unlikely -but not proven untrue- case of 2 messages sent simultaneously), and not due to actual decoding or parsing at the receiver end.
Latest test result shows the equivalent of one crash during about 35.000 transmissions (in lab conditions).
As a result and after advice from Robin2 I added a XOR checksum calculation stored as 2 hex values in one int variable, and this is added after the start marker upon transmission.
What needs to be done now is to extract/remove these 2 hex values and the first comma in the received message. Then calculate the XOR checksum again, on the received character array. And continue accordingly.

But this extends beyond the subject of this threat.

Deva_Rishi

communication takes place wirelessly with HC-12 433MHz radios: up to four transmitters, one receiver.
Ah i see you are using those, doesn't the virtual-wire library do a full CRC check ? as far as i know using that only allows for valid transmissions.

As a result and after advice from Robin2 I added a XOR checksum calculation stored as 2 hex values in one int variable, and this is added after the start marker upon transmission.
a 16-bit to verify seems cool.

What needs to be done now is to extract/remove these 2 hex values and the first comma in the received message. Then calculate the XOR checksum again, on the received character array.
With what i saw from the other thread, and/or with the info within my sketch, you should be able to manage that no problem.
Still you should be using the Virtual-wire library ! man those  433Mhz radios are far from reliable to begin with, and if they jitter long enough on your input line they may even cause your wdt to fire.
To 'Correct' you have to be Correct. (and not be condescending..)

brice3010

...
Still you should be using the Virtual-wire library ! man those  433Mhz radios are far from reliable to begin with, and if they jitter long enough on your input line they may even cause your wdt to fire.
35000 transmissions correct and one wrong is not too bad for an HC-12. Of course this is in lab conditions; that is why the checksum will be included.
CRC check on HC12: the datasheet does not mention it.

Deva_Rishi

it's not bad, but still Virtual Wirewill take care of the CRC check for you, pity you didn't make it overly clear what your setup was (or i missed it within your initial post) we could have skipped a lot of issues. VirtualWire can even make 'Raw' data reliable.
To 'Correct' you have to be Correct. (and not be condescending..)

cattledog

Quote
Virtual Wirewill take care of the CRC check for you
True. RadioHead and VirtualWire have a  CCITT CRC16 baked in, but is would be simple to add this to the serial protocol of the HC12. There are arduino libraries for this, and I think they would be valid for the ESP8266.

The HC12's are designed to run with a serial UART, and I would be interested to know if @Deva_Rishi has direct experience running them with an ASK protocol and VirtualWire/RadioHead

Quote
As a result and after advice from Robin2 I added a XOR checksum calculation stored as 2 hex values in one int variable, and this is added after the start marker upon transmission.
What checksum routine are you using? I thought it was a simple byte wise XOR which should give an 8 bit checksum. It its not a CRC.


Deva_Rishi

The HC12's are designed to run with a serial UART, and I would be interested to know if @Deva_Rishi has direct experience running them with an ASK protocol and VirtualWire/RadioHead
I had them running using the VW-library using more or less any pin ( i had 12 & 3) at 4000bps of course it is a blocking protocol, (for sure for tx one should wait until transmission is complete, think it does it using a timer interrupt) but the sheer simplicity of it is remarkable (sketches upon request) I don't know for what they were designed, but i tried them out and for me the 1-way communication, and the total lack of security meant that i decided that i would not use them for anything other then controlling kids-toys
To 'Correct' you have to be Correct. (and not be condescending..)

brice3010

True. RadioHead and VirtualWire have a  CCITT CRC16 baked in, but is would be simple to add this to the serial protocol of the HC12. There are arduino libraries for this, and I think they would be valid for the ESP8266.

The HC12's are designed to run with a serial UART, and I would be interested to know if @Deva_Rishi has direct experience running them with an ASK protocol and VirtualWire/RadioHead

What checksum routine are you using? I thought it was a simple byte wise XOR which should give an 8 bit checksum. It its not a CRC.


The test code is attached: indeed not CRC, simple XOR calculation. 8 bit? I thought the output is 2 hex values?

brice3010

I had them running using the VW-library using more or less any pin ( i had 12 & 3) at 4000bps of course it is a blocking protocol, (for sure for tx one should wait until transmission is complete, think it does it using a timer interrupt) but the sheer simplicity of it is remarkable (sketches upon request) I don't know for what they were designed, but i tried them out and for me the 1-way communication, and the total lack of security meant that i decided that i would not use them for anything other then controlling kids-toys
For my application, where 3 times an hour 5 values and a character need to be transmitted this I thought would be good enough.
This discussion starting now wakes my interest in further developing this transmission protocol, ie ASK protocol and VW or Radiohead.

Deva_Rishi

For my application, where 3 times an hour 5 values and a character need to be transmitted this I thought would be good enough.
Yeah it probably is.. a bit unfortunate that we went such a long way, to look for a mistake in a wheel (which there isn't really Robin's code is good) while there is a part (VW) that would remove any errors in the inputstream. (I suppose we would still be left with the strange strtok() behavior, which if it persists, a bug report to the ESP-core people should be filed.)
To 'Correct' you have to be Correct. (and not be condescending..)

Go Up