Society of Robots - Robot Forum
Software => Software => Topic started by: airman00 on October 16, 2008, 04:56:38 AM
-
This has been troubling me for quite a while
I have a RF Tx/Rx pair that act as a UART link. I want to send a packet of 2 bytes and have it receive it and process it . I've tried it over and over but it doesn't seem to work! I know the UART is working because if I have it check for only one byte continuously it will get it ( its not interference because when I change the data value to turn on different LEDs it works)
I checked the baud and its correct(both set to use 2400) . The receiver's MCU is an ATmega168 running at 8mhz , the transmitter's MCU is the Axon micocontroller running at 16mhz.
Here is some simple code for receiving a packet of only two bytes . The yellow LED turns on sometimes but the red is never on.
while(1){
RADDR = getByte(); // get address byte
data = getByte(); // get data byte
if (RADDR == 1) // check if address byte is equal to 1
{
yellow_on; // turn on yellow LED
if (data == 49) // Check if the received data is equal to 49
{
red_on;
}
}
}
The getByte() subroutine is as follows:
int getByte(void)
{
while((UCSR0A&(1<<RXC0)) == 0); // Wait until a byte has been received
return UDR; // Return received data
}
On the transmitter end all that I am doing is this :
while(1)
{
uart0SendByte(1);
uart0SendByte(49);
delay_ms(10);
}
-
most RF RX/TX pairs are optimised for manchester encoding. http://en.wikipedia.org/wiki/Differential_Manchester_encoding (http://en.wikipedia.org/wiki/Differential_Manchester_encoding)
in short, it is good practice when deailing with RF signals to transmit an even number of "1"s and "0"s.
this means your power output level is the same no matter what value you are transmitting. it also provides some form of error checking.
it dose mean it's not as simple as just connecting your UART to your TX module though.
to confirm this is the problem you are facing try transmitting "10101010" via the UART and see if that gets through.
i started documenting my solution to the issue but never finished it.
you can have a look here if you are willing to put up with my spelling mistakes and an unfinished format: http://mrdunk.googlepages.com/rflinkbetweenavrs .
dunk.
-
I found this if it helps anyone
http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html
@dunk
Thanks! I'm going to to try it out now
-
also dunk
how well did your RF link work using your solution? How much range did you get (approximately)?
Did you make your Manchester Encoder function already? Or should I make my own and post it online?
-
how well did your RF link work using your solution? How much range did you get (approximately)?
i have not explored the range fully.
the RF modules i'm using are rated up to 1km and there was this one time when the wind decided it was taking my plane for a joyride i got close to that distance without loss of signal.
so i guess i'm saying you should get close to the rated distance of your RF modules.
Did you make your Manchester Encoder function already? Or should I make my own and post it online?
yea. made it. see below.
not particularly pretty but fairly human readable.
mine is not the full spec Manchester Encoding as it does not send the UART start bits compliment but it is close enough to work with my RF modules. i'd imagine it will work for yours too.
so in the comments in the following code a "nibble" is half a byte.
either the first 4 bits or the last 4.
TX:
// **** Data. low nibble then high nibble to make full bite. ****
// each data byte sent as pesudo manchester encoding so every bit is followed by inverse of the same bit.
// this means every byte of data will need 2 byes to be transmitted on the UART.
for (n=0;n<4;n++){ // loop through low nibble of data2
if(data & (1<<n)){
temp |= (1<<(n*2)); // set bit on n.
temp &= ~(1<<((n*2)+1)); // and set inverse of bit on n+1.
}
else{
temp &= ~(1<<(n*2));
temp |= (1<<((n*2)+1));
}
}
UARTout(temp); // transmit low nibble
for (n=0;n<4;n++){ // loop through high nibble of data2
if(data & (1<<(n+4))){
temp |= (1<<(n*2)); // set bit on n
temp &= ~(1<<((n*2)+1)); // and set inverse of bit on n+1
}
else{
temp &= ~(1<<(n*2));
temp |= (1<<((n*2)+1));
}
}
UARTout(temp); // transmit high nibble
RX:
temp=0x00; c=0;cc=0;
while ((!c) & (cc< UART_timeout) & (!error)){ // wait for low nibble to arrive on UART
c = UARTin();
cc++;
}
for (n=0;n<8;n+=2){
if((c & (1<<n)) != (c & (1<<(n+1)))) { // make sure n is opposite of n+1 (fake manchester encoding.)
if (c & (1<<n)){
temp |= 1<<(n/2);
}
else{
temp &= ~(1<<(n/2));
}
}
else{ // bit n not opposite of n+1. (ie. corruption has occured.)
error=1; // set error flag
//n=9; // and stop for loop.
}
}
c=0;cc=0;
while ((!c) & (cc< UART_timeout) & (!error)){ // wait for high nibble to arrive on UART
c = UARTin();
cc++;
}
for (n=0;n<8;n+=2){
if((c & (1<<n)) != (c & (1<<(n+1)))) {
if (c & (1<<n)){
temp |= 1<<((n/2)+4);
}
else{
temp &= ~(1<<((n/2)+4));
}
}
else{ // bit n not opposite of n+1. (ie. corruption has occured.)
error=1; // set error flag
}
}
dunk.
-
thank you very much !
can someone explain what UART_timeout is?
EDIT:
Is this
while ((!c) & (cc< UART_timeout) & (!error)){ // wait for low nibble to arrive on UART
c = UARTin();
cc++;
}
the equivalent of this:
while((UCSR0A&(1<<RXC0)) == 0); // Wait until a byte has been received
return UDR; // Return received data
-
use RXC0 checking instead of a timeout.
-
nope.
for my application i didn't want to use RXC0.
it is possible the preceding byte is in fact interference and there is no 2nd byte coming.
for that reason i increase cc every iteration of the while loop and if it ever reaches the value in UART_timeout then it continues (and flags an error when the encoding check fails).
what is missing from my RX code snippet is i actually started by sending and at the RX end testing for a start bit.
if you were going to use this code as is you would need to strip out the UART_timeout from the first nibble so the program waits there indefinitely..
you'd still want a timeout on the 2nd nibble though in case interference caused the code to pass the first nibble in error.
dunk.
-
what should the timeout value be?
and also the data byte in my application has a possibility of only 125 values. Nothing more than that . Would it make sense to just use a long list of preprogrammed defines and each define having the Manchester-encoded byte.
How many possible combinations are there in binary( 8bits) that have an equal number of 1s and 0s ?
-
How many possible combinations are there in binary( 8bits) that have an equal number of 1s and 0s ?
Let me just answer my own question here.
I asked on VBforums for code to generate the appropriate numbers and it turns out there are 70 combinations. I guess I have to do Manchester Encoding( unless I reduce the number of possible values , which would probably happen anyways)
Here is the code in VB6 for those who want it: http://www.vbforums.com/showpost.php?p=3359427&postcount=7
-
what should the timeout value be?
obviously it depends on your clock speed and baud rate.
i found mine by trial and error. (start high so it definitely only times out when there is an error and decrease the value until it stops working properly.)
How many possible combinations are there in binary( 8bits) that have an equal number of 1s and 0s ?
i'm afraid you don't have this part quite right yet. my initial description of manchester encoding was too limited.
so for manchester encoding each bit bust be followed by it's compliment. (ie if you send a "1" the next bit must be a "0" and vice versa.) this gives 16 possible combinations.
i'm not saying you need true manchester encoding. it depends what your RF modules will do.
on the RF modules i was using the binary number 11110000 would not work.
11011011 would work 75% of the time.
11010100 would always work (even though it's not manchester encoded).
i implemented manchester encoding partly because of the built in error checking.
if you just want a lookup table with 125 values i suggest you start testing 8 bit numbers and seeing which ones work. while there would not have been 125 values for my RF modules there may be for yours.
question: have you confirmed you can send a number like 10101010 yet?
it would be worth checking this is indeed your problem.
dunk.
-
question: have you confirmed you can send a number like 10101010 yet?
it would be worth checking this is indeed your problem.
yep I sent that byte and it got it perfectly
whats interesting to note is that almost all of the "noise" values had an equal number of 1s and 0s.
Another thing which I might try is to constantly send a dummy byte ( it has no function , except keep the Rx on tune) and then once I need to send the real data it will pick it up right away. From my tests it seems that if I do this there will be minimal noise.
My applications demand got even lower. I need to send a color code to a receiver which shows that color on a RGB LED. So I guess I'll test out the 70 binary numbers my VB program generated and find the 45 best that work.
I will test it out as follows :
Do a for loop (transmit a certain amount of times) for each of the values
Send dummy byte a few times to mark a change in byte
Change the byte sent and do a for loop
Repeat for all the bytes (0-255 or maybe I should just do the 70 numbers generated by the VB program?)
-
he he
I upped the voltage on the transmitter from 5V to 12V. It now gets literally everything - from 0 to 255.
I did some tests(the for loop of sending numbers from 0 to 255) from the 1st floor of my house to the second floor and it got everything I sent to it.
I'm all about eliminating error , so do you think I should do Manchester Style bytes anyways, just in case I might have some sort of error?
Here is the link to the Tx/Rx pair by the way : http://www.sparkfun.com/commerce/product_info.php?products_id=7816
Is that specific pair manchester encoding optimized?
-
I have another issue
OK heres my setup now : Transmitter is running the following code and sending a packet continuously
dummy = 99;
RADDR = 68;
data = 17;
checksum = RADDR + data;
while(1)
{
delay_ms(1);
uart0SendByte(dummy);
delay_ms(1);
uart0SendByte(RADDR);
delay_ms(1);
uart0SendByte(data);
delay_ms(1);
uart0SendByte(checksum);
}
The receiver is receiving the values from the receiver and right away sending it through USB to my terminal windows
In the terminal window I see crap values for a while and then all of sudden the correct bytes are seen except that they are each shown too many times. A packet is supposed to be [ 99,68,17,85] . What happens is that each byte of that packet is copied multiple times so its like [99,99,99......99,68,68,68...... , etc.]
It also seems like the packet is getting received backwards. look at the log below, its received in the following order 85,17,68,99
Anyone know how to fix this and have a proper byte sent?
Here is the log of the values sent through USB ( note that values are in decimal )
EDIT : Log removed since it was too long and is shown later on in this post
-
are you sure your program at the receiver end is pausing until it receives a new character rather than just reading what's in the buffer?
that would not explain the order being reversed though....
i'd try a program like this at the transmitter end if i was looking for weird timing issues:
while(1){
for(t = 0; t < 255; t++){ // increase number of ms between TXs.
for(i = 0; i < 255; i++){ // print a string of values from 0 to 255. (easier to see a pattern this way.)
uart0SendByte(t);
delay_ms(t);
uart0SendByte(i);
delay_ms(t);
}
}
}
dunk.
-
i tried what you said dunk and I got these numbers
225
232
7
7
7
5
8
8
24
30
8
8
49
55
8
8
74
EDIT: shortened for content
-
When the transmitter runs this code:
while(1){
SendByte(15); // 0F in hex
SendByte(16); // 10 in hex
}
The macro for SendByte was recommended by AVRfreaks so that way its not AVRlib dependant
void SendByte(char c) {
while (!(UCSR0A & (1<<UDRE0)));
UDR0 = c;
}
I get all the packets and then all of a sudden it just shows FF (255 in decimal ) and occasionally the proper bytes pop up among the FF.
Is this an error because of the transmitter? or maybe its from the receiver which is just taking in bytes and sending it through USB
Receiver uses this code:
while(1)
{
data = uart0GetByte();
uart1SendByte(data);
}
Heres a log of what happens
0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 0F 10 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 10 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0F FF FF
-
and what if you keep that receive program and just repeatedly send 0xAA ?
(ie, binary 10101010)
dunk.
-
and what if you keep that receive program and just repeatedly send 0xAA ?
(ie, binary 10101010)
dunk.
then i get only 0xAA and no FF ( which is 255)
Any idea why the FF pops up when I send two bytes?
-
sounds like you are back to the issue with the module needing to send manchester encoded data.
try sending a series of manchester encoded bytes and seeing if you have problems with that.
this is the full series:
01010101
01010110
01011001
01011010
01100101
01100110
01101001
01101010
10010101
10010110
10011001
10011010
10100101
10100110
10101001
10101010
dunk.
-
tried what you said dunk , I still get the FF
-
Here is some more details on the FF section
OK so after it receives the code correctly a few times then it starts to go into this:
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 55 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 65 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF A5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 55 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 65 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF A5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 55 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 65 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF A5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 55
Please note that between each correct byte there is an equal number of FF. There are exactly 40 FF between each correct byte . Anybody know why?
-
so it works properly for 10101010 but not any other sequence?
weird. i'm out of ideas.
what happens if you reset your transmitter circuit while it's doing the FF sequence?
what happens if you reset your receiver circuit while it's doing the FF sequence?
what happens if you stop transmitting for a while then restart in the program at the transmitter end?
does it work for a while then revert to your FF pattern?
dunk.
-
so it works properly for 10101010 but not any other sequence?
no it works fine whenever I send only one byte over and over. When I start sending more than one byte at a time , it starts with the FF.
As for your other questions I'm gonna try it out now.
-
I figured it out a bit
I wrote my own routines for each of the GetByte and SendByte and the result was that I eliminated the FF. The reason for the FF was that each time the byte was read it was empty and returned a -1 -- which is shown FF in a character.
Here is my SendByte routine
void SendByte(char c) {
while (!(UCSR0A & (1<<UDRE0))); // wait until you are able to send a byte
UDR0 = c;
}
Here is my getbyte routine
int GetByte0(void)
{
while((UCSR0A&(1<<RXC0)) == 0); // wait until a byte is received
return UDR0;
}
-
I did some more tests and it looks like I get 138 correct 4 byte packets ( in correct order) in 30 seconds . Thats 552 bytes in 30 seconds and 18.4 bytes per second(147.2 bits per second).
I did another test , but this time for 1 minute long - in 1 minute it received the reverse packet ( 5A,59,56,55) 252 times - approximately the same values as my 30 second test.
Please note that I am running this at 2400 baud.
Btw the reason the test above had such good accuracy was because all the bytes received were received backwards - meaning the correct packet I intended to send was
SendByte(data1); //55
SendByte(data2); //56
SendByte(data3); //59
SendByte(data4); //5A
Issue #2:But in my log I received 5A, 59, 56, 55! How come I'm getting it backwards???
Issue #3: Listen to this scenario - the transmitter is on and supposed to be sending (55,56,59,5A) . Now I turn on the receiver and it gets that whole reverse packet nonsense . Now I turn off the receiver and turn it back on. It keeps getting that nonsense . I turn it off and on once more ( note that the transmitter is still on) and it gets reverse character and reverse packet! Meaning now the correct packet is received as {A5 95 65 55 }
Part of my log:
65 A5 55 A5 65 95 65 55 A5 65 95 65 55 A5 65 95 65 55 A5 65 55 A5 55 A5 95 55 65 55 A5 95 55 65 55 A5 95 65 A5 55 A5 95 65 A5 55 A5 95 65 A5 55 A5 95 65 A5 95 A5 95 65 55 95 A5 95 65 55 95 A5 95 65 55 95 A5
Issue #4: Occasionally after turning on and off the receiver portion - but leaving the transmitter on and transmitting - I receive the hex number 69 instead of A5 . Note that this is only when I get the packets in reverse character and reverse packet
-
I did some more tests and it looks like I get 138 correct 4 byte packets ( in correct order) in 30 seconds . Thats 552 bytes in 30 seconds and 18.4 bytes per second(147.2 bits per second).
Please note that in that test I got the reverse packet - A5 95 65 55 not the correct packet
Issue #4: Occasionally after turning on and off the receiver portion - but leaving the transmitter on and transmitting - I receive the hex number 69 instead of A5 . Note that this is only when I get the packets in reverse character and reverse packet
This means that each time an A5 is usually seen it is replaced by hex number 69. The A5 never shows up in that case
I can't seem to find the relationship between A5 and 69 - I dunno why it would be replaced.
-
I changed my transmit code to this:
SendByte(0); //0 - a dummy byte that we don't care if its lost
SendByte(data1); //55
SendByte(data2); //56
SendByte(data3); //59
SendByte(0); //0 - a dummy byte that we don't care if its lost
Adding in a dummy byte of 0 basically fixed all my issues - but I still don't know why those issues came up.
Also changed all baud rates to 4800.
I now get a correct 3 byte packet 586 times in 30 seconds - or 19.5 bytes per second. Total of 5307 bytes sent in 30 seconds and 1758 of those bytes were correct packets - so I guess 33% accuracy for a 3 byte packet - which kind of sucks.
Anything I can do to improve this accuracy even more?
-
you should be getting far better speeds than that.
rather than send a 0x00 byte between packets what if you send no byte at all?
try putting a few ms pause between packets.
also, i presume you have tried putting a delay between bytes?
the module datasheet should tell you the optimum baud rate for the modules.
this value will *probably* be for manchester encoded data so half the value your UART is sending at.
let me know if you want to try my full RC firmware just to see if your modules behave any differently with my code.
i don't see why they would though. i can't see anything particularly different we are doing with the timing other than i have a delay between packets.
dunk.
-
Heres what I tried, and here is my results (all tests were run at 4800 bps)
For the following combinations I the transmission is really crappy and I get less than 300 3 byte packets in 30 seconds.
0,55,56,59,0 with 10ms delay after each packet, with 5ms delay after each byte, with 3ms delay after each byte, with no delay at all
0,55,56,59 with 10ms delay after each packet, with 5ms delay after each packet ,with 5ms delay after each byte, with 3ms delay after each byte, with no delay at all
So far the best I've gotten is this combination :
0,55,56,59,0 with 5ms delay after each packet and 852 correct 3 byte packets in 30 seconds - 28.4 packets per second == 85.2 bytes per second - still pretty crappy
I'm going to experiment with different delay times after each packet.
Datasheets are provided on this page for my receiver and transmitter : http://www.sparkfun.com/commerce/product_info.php?products_id=7816
Thanks dunk.
-
i had a read of the datasheets.
they don't mention any special encoding being required. manchester encoding should not be required.
if i were you i'd post your findings on the Sparkfun forum.
see if you can find anyone who has successfully used them.
dunk.
-
I'm posting the question now
thanks
-
hey dunk maybe I should try these modulation styles that are stated in the datasheet?
MO-RX3400-A is an ASK receiver module. The MO-RX3400-Ais based
on a single-conversion ,super-heterodyne receiver architecture and
incorporates an entire Phase-Locked Loop (PLL) for precise local oscillator
generation. It can use in OOK / HCS / PWM modulation signal and
demodulate to digital signal. MO-RX3400-A had a high performance and
easily to design your product.
OOK - http://robotics.eecs.berkeley.edu/~sastry/ee20/modulation/node5.html ( no idea about this)
HCS - no fricken idea , google yields nothing
PWM - good ole Pulse width modulation http://en.wikipedia.org/wiki/Pulse-width_modulation
This brings me to another question :
UART just happens to work with these , but isnt intended to work like that. But so many people have it working
oh one big thing to note - the bastardly Sparkfun people's tutorial says that pin3 of the receiver should be left alone. Over here : http://www.damonkohler.com/2008/09/arduino-rf-link.html it correctly states that in the datasheet the two data pins should be connected to each other. Whatever, i'll try out that data pin wiring changes tomorrow.
-
OOK is just any digital signal that passes data by switching between 2 logic states.
your UART is an implementation of this.
so, yea, no complicated transmission schemes *should* be required....
one more thing actually,
when i was first playing with my RF modules i found they were particularly susceptible to noisy power supplies.
any sort of slight brown out of the power caused transmission errors.
it caused me lots of headaches until i realised what was causing it.
are you sure your power to the modules is clean?
a last piece of debugging for you as well:
you've probably tried this but just to confirm it's definitely your RF modules at fault and not your code,
have you tried removing the RF modules from the circuits and joining the TX pin on one AVR to the RX pin on the other?
dunk.
-
what do you mean by clean power?
-
what do you mean by clean power?
constant voltage.
no spikes or dips.
completely constant voltage.
when i was building my RC circuits my servos were causing a *slight* drop in the RX power.
it was not even nearly enough to affect the AVRs program but it caused the receiver module to give really nasty results.
dunk.
-
Receiver power is connected to Axons regulated line , Transmitter line is connected to the other axons unregulated line. 12V Nimh battery is connected to Transmitter Axon. No other circuitry is on Transmitter axon besides the transmitter. Is that clean enough?
-
ok this is wierd
Jumpered Tx to Rx with a wire and I get this
55 56 56 56 59 59 59 59 59 55 55 55 55 55 55 56 56 56 56 56 59 59 59 59 59 55 55 55 55 55 55 56 56 56 56 56 59 59 59 59 59 55 55 55 55 55 55 56 56 56 56 56 59 59 59 59 59 55 55 55 55 56 59 59 59 59 55 55 55 55 55 56 56 56 56 56 59 59 59 59 59 59 55 55 55 55 55 56 56 56 56 56 59 59 59 59 59 59 55 55 55 55 55 56 56 56 56 56 59 59 ....
As you can see I get a repeat of bytes.
heres my code:
SendByte(data1); //55
SendByte(data2); //56
SendByte(data3); //55
and here are my subroutines.
Here is my SendByte routine
void SendByte(char c) {
while (!(UCSR0A & (1<<UDRE0))); // wait until you are able to send a byte
UDR0 = c;
}
Here is my getbyte routine
int GetByte0(void)
{
while((UCSR0A&(1<<RXC0)) == 0); // wait until a byte is received
return UDR0;
}
This is really really wierd. What can I do to fix this mess?
Also, can I just use PWM on the transmitter and take an ADC on the receiver?
P.S. dunk I think we scared away all the forum members from this post ;)
-
ok, well that's a little progress.
at least you now know the problem is not with the RF modules.
do you have a level shifter built so you can feed the TX side into your PC serial port?
you could verify the TX code that way. make sure you are transmitting the right thing.
getByte and sendByte look fine to me.
i think you are going to have to post your full programs here.
i'll confirm whether i see the same weirdness on different hardware.
dunk.
-
I do not have a shifter.
As for my program , there is nothing to show
I did the tests with two Axons , so that way it was easier to program quickly. Forget the ATmega168 for now. Both programs are standard axon setup code , with uart0 set to 2400 baud. I guess I can't really verify the transmission directly. I could do it indirectly and have uart1 ( the USB) send the same thing as uart0 .
Why would there be repetition of bytes in a transmission anyways?
Receiver just does
void report(void)
{
int data;
while(1)
{
data = GetByte0();
SendByte1(data);
}
and Transmitter just does:
void send(void)
{
while(1){
//#define data1 0b01010101
//#define data2 0b01010110
//#define data3 0b01011001
SendByte(data1); //55
SendByte(data2); //56
SendByte(data3); //59
}
}
Also, can I just use PWM on the transmitter and take an ADC on the receiver?
-
Hi,
I have the same tx/rx pair. I also got the other pair operating on a different frequency so i could have both sides of devices sending and receiving.
I havent used them for about 4 months now but from what i remember doing with them is basically they are wysiwyg style senders meaning what is seen on the transmit pin of 1 module is what you get on the receive pin of the other module.
I made a packet style system which sent 8 bytes per packet with some startbytes of (|TX|S|) and end bytes of (|TX|E|) to know when the packets were being sent and when the end of the packet was finished. I know that it is probably unnecessarry but I also built in a system where each packet was transmitted twice to ensure data integrity.
An easy way to test these modules is to power both the transmitter and receiver up, then attach your multimeter to the rx pin on the receiver (and of course ground) and connect +5v or GND to the tx pin on the transmitter and monitor what the multimeter has on its display, it should change accordingly.
Also you mentioned a couple of posts ago that you jumpered the tx pin to the rx pin, this in itself explains the repetition of bytes it similar to the sqeaky noise you get when you put a microphone next to a speaker.
There was a post where you showed occasional bytes being received but spaced with FF FF FF etc... , presumably this is when the transmit pin is left floating high or maybe low? probably in between data transmission.
Youve got to know that these are quite raw radio modules and are going to take a lot of work to use them properly (I realised this and then told myself that i could have spent another $60 on one of the other transmission systems or put the effort in to get them working).
One more quick note. Unless you have a dedicated microcontroller just for this module alone on the receive end, then you will never reliably be able to use them for an interrupt on UART change which is why i stopped using them.... (I might be using them again a couple of months time if i get a chance to work on my new project)
-
thanks for the reply paulstreats
so what I can do now to get these things to work right? Can you share some of your code ( assuming its in C )
Also paulstreats few questions : What voltage was the transmitter at ? Did you use a capacitor between antenna and GND ?
and I do have a dedicated microcontroller for the receiver .
How well did the modules work ? How much 8 byte packets did you get per second? How accurate was it?
I have a month to get these things working , so I'm not so worried about time and effort.
thanks again
-
Also you mentioned a couple of posts ago that you jumpered the tx pin to the rx pin, this in itself explains the repetition of bytes it similar to the sqeaky noise you get when you put a microphone next to a speaker.
hey Paul, nope. he means the TX on one AVR to the RX on another.
basically testing the code without the RF modules. just a wire between the UARTs (and a common GND ).
Airman,
yea. nothing complex with that code.
you 100% sure all interrupts are disabled, WDT disabled, brownout detection disabled etc no the AVRs?
can you try transmitting a number sequence again to try and confirm whether you are seeing repetittions of the same byte or whether you are only getting one byte in every 4.2 ?
something like this:
while(1){
for(i = 0; i < 255; i++){
for(j = 0; j < 255; j++){
SendByte(i);
SendByte(j);
SendNewLine();
}
}
}
Also, can I just use PWM on the transmitter and take an ADC on the receiver?
sure. just make sure the PWM frequency is around 2400bps.
dunk.
-
I guess I can't really verify the transmission directly. I could do it indirectly and have uart1 ( the USB) send the same thing as uart0 .
I think you can hook up a serial LCD in paralel with the RX pin on the receiving Axon (or a RS232 interface to your computer). That way you can directly see what it is received. You can use the LCD hooked in paralel with the TX pin of the first Axon and the RS232 interface to the RX of the receiving Axon, that way you can double check what is transmited and received. Hmm... never tryed but I think it may be possible to use 2 RS232 to USB interfaces and open 2 sesions of telnet on the 2 USB serial ports and compare the signals. This way you can determine if the errors come from the radio modules or not.
-
hey Paul, nope. he means the TX on one AVR to the RX on another.
basically testing the code without the RF modules. just a wire between the UARTs (and a common GND ).
he he .. I should really read full posts instead of just scanning through them ;D
What voltage was the transmitter at ? Did you use a capacitor between antenna and GND ?
I just used the transmitter at regulated 5 volts, I never needed to use it at a full 500metre range, I just wanted to use it instead of a wired connection to hyperterminal.
I never used a capacitor between the antenna and ground, though I did solder a bit of wire to the antenna just to make myself feel better :) (I could only think that unless you are completly accurate with the type and values of the capacitor then it is going cause a long drop off after a high send, such as when you connect a capacitor to an led then connect power. when you remove the power the led light fades over time rather than turning crisply off. A capacitor would do the same with the transmitting antenna meaning that the signal is not going to be crisp. I imagine that it could be advantageous but you really would have to get the perfect combination).
The code was very simple really it was just standard sending the bytes through the uart and the receiving side similar, ill dig up the code for you but it doesnt have to be difficult, just a bit of thought into it.
I used the modules at 2400 baud, obviously bytes being sent twice reduced the transmission rate. Even with this I did get an occasional faulty byte meaning that i had to have some other system, I remember two different systems either a transmit the full packet back or just transmit a confirm byte cant remember which i went with. Neither of these will work for you if you only have the one module though because the receive end cant send any data back.
In your case I would try and send each packet maybe 3 or 4 times and then compare them at the receive end hopefully you should get 2 or more matching packets, if not then you have no idea which one is good and which one is bad, so the more times you send the same packet the more chance you are of getting 2 matching packets meaning that they are the correct packet. In the event of not getting 2 matching packets you'll have to build in a flush/reset system of some variety...
Also, can I just use PWM on the transmitter and take an ADC on the receiver?
I would never have thought of doing that ???
-
ok thanks
@paulstreats
so approximately how much bytes per second were you getting ? I need a maximum 21 three byte packets to be received in one second. The RF link at 2400 baud can do that without a problem , right?
Did you use AVRlib or did you do all coding from scratch?
@dunk
you know what I just realized ! uart.c (from AVRlib) makes use of the interrupt for the UART. I'll disable that and do some tests tomorrow night. I've been using AVRlib uart.c all this time to initialize the UART.
-
2400 baud translates as 2400 bits per second loosely. So byte per second are 2400 / 8 (since there are 8 bits in the byte). So 2400 baud can send 300 bytes per second if used optimumly.
The system that I used sent 6 start bytes 8 data bytes and 6 stop bytes meaning 20 bytes per complete packet. so 2400 baud (300 bytes per second) / 20 (bytes per packet) equals exactly 15 packets per second.
If you used 6 startbytes 3 databytes and 6 stopbytes that would give you 20 packets per second. You could reduce the amounts of start and stop bytes but the more start bytes you have the more sure you can be that you are receiving a real packet and not an interference pattern.
Did you use AVRlib or did you do all coding from scratch?
I use pic's but the code should be similar - ish, All you have to do is place the byte to be sent onto the UART register and the pic does the rest. I'll post the code I used in about 8 or 9 hours (tonight for me :)) And i'll comment it where I can....
edit
-----------------
Also my code does use the interrupt on uart, but throws any bytes away that dont conform to the packet start sequence.
-
My module supports up to 4800 baud , so I guess I can go up to there and double my packet
Also my code does use the interrupt on uart, but throws any bytes away that dont conform to the packet start sequence.
also paulstreats some things to note :
I only need two bytes of data - they are address and data . Thats it . So I guess I don't need the start bytes and stop bytes??? So what would the packet form be ?
-
It is definately good practise to use start bytes and stop bytes. When the start bytes are received in sequence the receiving program then know that the following 2 bytes are data, and you can be sure to get them in the correct order. These modules do suffer from interference, so the interference can translate into uart transmission and give false signals. Also without a start byte how would your receiver program know which bytes were data and which were register addresses?
You can probably get away with just 2 start bytes.
in your case the packet could consist of just 6 bytes in total. 2 start bytes, 2 data bytes and 2 stop bytes (just for good form.)
so you would want to create a char array like this:
sendarray[0] = "|" //start byte 1
sendarray[1] = "S" //start byte 2
sendarray[2] = <address byte>
sendarray[3] = <data byte>
sendarray[4] = "|" //end byte 1
sendarray[5] = "E" //end byte 2
then use a put string command to send the entire array instead of doing it byte by byte yourself.
so:
puts(sendarray); //send all six elements of the array
on the receive end you'll need something like this:
boolean potential_packet = false;
unsigned char receivedarray[6]; //this is where the packet will be stored
unsigned char packetflag = 0 ;
void interruptonuartfunction{ //just here to show what to do inside the uarts interrupt function
if (rxregister eq "|"){ //the rx register is where the microcontroller stores the received byte
potential_packet = true; //because its found the first character of a start byte, we have a potential packet
}
if (potential_packet == true){
store_packet();
}
rxinterruptflag=0; //were all done so reset the microcontrollers interrupt flag and lot it get the next byte
}
void store_packet(){
receivedarray[packetflag] = rxregister; //store the contents of the rxregister in the array
packetflag++;
if (packetflag == 6){
potential_packet=false; //the packet length has come to an end
packetflag=0; //reset the packet flag to 0
}
}
You should then have a char array of 6 bytes which contain the packet. So just check the start bytes and stop bytes to ensure they are the correct characters "|" , "S" and "|", "E". If so then the two bytes at receivedarray[2] and receivedarray[3] are your address and data bytes. If the start bytes or stop bytes dont conform then it isnt a true packet either made by random white noise or interference. In this case nothing is done, the received packet can be wasted........
-
wouldnt it be better to do address,data,checksum - so I can get rid of needing all those start and stop bytes?
-
you could use a checksum, this operates in a similar way as a stop byte but also keeping a sequence.
The start and stop bytes are just the way that i did it myself and offer a solution to the problem. It was also from my view the best way of countering interference and noise problems and ensuring that i got accurate data.
When i come to use them again I might incorporate a checksum along with start and stop bytes, it could help speed my old system up rather than having to acknowledge data back and forth.
Again if you dont have a known start sequence, how does the receiver know which are the 3 bytes you are sending. If the receiver just picks up noise to start with this can be interpreted as the address byte then when you transmit the address byte the receiver will see this as the data byte and the data byte will be seen as the checksum. Probably meaning that the sequence gets ignored. Most things you can do this with but the noise and intereference can mess up a simple transmission thats why i went with start and stop sequences to differentiate between noise and data
-
A thought did occur to me earlier that if you use a pull down resistor on the transmit pin of the radio module then it might cut out the noise altogether.... maybe ::)
-
hey Airman,
did you make any progress with this?
was it the UART interrupt interfering with your receive function?
i'm guessing silence either means it's working
or you got sick of it and decided to leave it alone for a wile....
dunk.
-
i've been crazy busy and haven't had a chance to test it out yet
I'll do some tests tonight
-
I disabled the interrupts by commenting one line for each of the uartInit
// enable interrupts
//sei(); <---- this was usually uncommented , I commented it
I seem to get slightly better results then before. No more repeating characters but still crappy transmission. Again I intended to send 55,56,59 . Looks like I have a lot of 59,56,55. Is transmission supposed to be perfect when jumpered together?
56 55 56 55 56 56 55 59 56 59 55 59 56 56 55 59 56 59 56 55 59 56 55 59 55 56 55 59 56 55 59 55 59 56 55 56 55 59 56 59 59 56 55 59 56 55 56 55 55 56 55 56 55 59 56 59 55 56 59 56 56 56 55 55 56 59 56 55 59 56 55 56 55 55 55 56 59 55 59 55 59 59 59 56 59 55 56 56 56 55 59 56 55 55 59 59 59 56 55 55 59 55 59 56 55 56 59 56 59 56 55 56 55 59 56 55 59 56 55 56 55 56 59 56 59 56 55 55 59 56 56 55 59 56 56 55 59 56 55 59 56 59 56 55 59 55 59 56 56 56 55 55 56 55 59 56 55 56 59 56 55 59 56 56 55 56 55 59 56 55 59 55 59 59 55 56 55 55 56 56 59 59 55 59 56 56 56 55 59 55 56 56 55 59 55 59 55 59 56 56 56 56 56 59 55 55 59 59 59 56 55 56 55 55 59 56 56 55 56 55 59 55 59 56 55 55 55 56 59 56 55 59 56 59 56 55 56 55 59 55 56 55 56 55 59 56 55 56 55 59 55 56 55 56 55 59 56 56 59 55 59 59 55 59 56 59 56 56 59 56 55 59 56 55 56 56 56 59 59 56 56 59 55 59 56 55 59 55 59 56 56 59 56 55 56 59 59 56 55 59 56 55 56 55 59 56 59 56 55 59 59 55 56 59 56 55 55 56 59 56 55 55 59 56 59 56 59 55 59 59 56 55 59 59 56 55 56 55 59 56 56 55 59 56 56 55 56 55 56 56 56 59 59 56 56 59 55 59 56 59 55 56 59 56 56 59 56 55 59 56 55 55 55 59 56 59 56 59 55 55 55 59 56 55 59 55 59 56 59 56 55 59 56 59 56 55 56 55 55 55 56 55 56 59 55 56 55 59 55 59 56 55 59 56 59 56 55 56 59 59 56 55 59 55 55 55 59 55 59 59 59 55 56 55 56 55 59 56 55 56 55 55 59 56 59 55 59 56 56 59 56 55 56 55 59 56 59 59 55 59 56 55 59 59 59 56 59 55 55 59 56 59 55 59 56 59 56 55 59 56 55 56 56 55 56 55 55 56 56 59 56 59 56 55 56 55 56 55 56 55 59 55 59 56 55 56 56 59 56 56 55 59 55 59 55 55 59 55 59 55 56 56 55 55 55 56
-
Fixed it , I get all the packets correctly when I'm jumpered . I'll do tests over RF in the next few days.
you need to remove the bit registers that enable Interrupts. Just uncommenting sei() doesn't do it.
Here's the code:
void uart1Init(void)
{
// initialize the buffers
uart1InitBuffers();
// initialize user receive handlers
UartRxFunc[1] = 0;
// enable RxD/TxD and interrupts
outb(UCSR1B, BV(RXEN)|BV(TXEN)); // <------- took out RXIE and TXIE
// set default baud rate
uartSetBaudRate(1, UART1_DEFAULT_BAUD_RATE);
// initialize states
uartReadyTx[1] = TRUE;
uartBufferedTx[1] = FALSE;
// clear overflow count
uartRxOverflow[1] = 0;
// enable interrupts
//sei();
}
-
did the RF test and I am incredibly happy.
2018 correct 3 byte packets in 30 seconds. That's 67.2 packets a second ---> 201.6 bytes per second. Mind you this is at 2400 baud.
I'm going to switch up to 4800 baud and also play around with the delays I use. Heres the code I used to get 2018 packets per second.
while(1){
SendByte(data1); //55
delay_ms(5);
SendByte(data2); //56
delay_ms(5);
SendByte(data3); //59
delay_ms(5);
}
Is there some way to calculate the optimum delay in between bytes based on what baud you are using?
Thanks for all the support guys ! I really appreciate it. I'll put up some documentation in the coming weeks.
-
Im not sure that you need to set any delays at all, It wont send the data faster than the predetermined baud rate and the send functions such as SendByte() will hold the program until the buffer is ready.
-
yea, you should not need any delay between bytes.
try it and see what works best.
well done. got there in the end.
dunk.
-
OK so without delay I get screwy packets . I get 65 , 95, 55 instead of the proper 55,56,59. I also get this screwy packet when I have a delay of 1ms between packets . Other higher than 1ms delays give me the proper bytes perfectly.
At 2ms delay between packets I get 2396 correct 3 byte packets in 30 seconds. That means around 80 packets per second which is 240 bytes per second. Mind you this is at 2400 baud. I might go up to the maximum 4800 baud later on if need be.
Few questions now for you guys:
1. how come with no delay I get those screwy packets?
2. also is this a reliable way of encoding the data - start bit,address,data,checksum ( a 4 byte packet)
3. Whats the theoretical maximum bytes per second of 2400 baud - is it 300 bytes per second? ( = 2400/8 )
4. What percentage of the theoretical maximum is considered normal ? 80% perfect considered good, 50% , etc.
5. Is it true that if you go up to a higher baud rate then your risk of error is increased?
Thanks
-
Hi,
You got it all working which is good, even with a delay im sure that you can use the system.
1) Im not sure why this is. Maybe Dunk will know better. Maybe its the receive end not being ready, or maybe its the uart buffer on the transmit end?
2)It is reliable from my point of view. This is only needed because of the raw radio modules. With a hard wired system you could do without the start bit and for non critical applications even the checksum could be eliminated.
3)2400baud/8 = 300 bytes per second theoretically. Correct!
4)In a computer wired system 99.99 - 100% is to be expected these days (there is quite often a bit phase difference depending on the clock speed of the device), microcontroller to microcontroller can range between 90% - 99.99% but those radio modules you should be aiming for about 80%
5)The baud rate is device dependant. If all devices support a higher baud rate then no risk of error should be present. The radio modules say that they transmit readily at 4800 baud so there should be no problem in increasing this. If they were 4800baud maximum transfer speed then you should be prepared for more errors. Also if you look at you microcontroller datasheet, It should give you the baud rate verses crystal speed lookup table. There will be %error included on the table. It can be surprising that a mid range baud rate can yield more errors than a high speed baud rate.
Remember that computers etc.. that receive bad packets with bad checksums can send a message back saying they havent received it correctly and that it should be sent again. With your 1 way radio system you cant do this so you are going to have to accept some bad data eventually. Its either accept occasional bad data or send each packet 3 times and if 1 messes up then you can compare them all. If 2 of the packets are the same then that is the correct data.
-
1. how come with no delay I get those screwy packets?
1) Im not sure why this is. Maybe Dunk will know better.
i wonder if the RF modules are optimised for more stop bits than your microcontroller sends by default?
i'm guessing though.
i'd not worry about it if i were you as long as you have a workable solution.
when it comes to encoding,
as Paul says, nothing is 100% reliable.
sooner or later you are going to send a mangled set of bytes and by coincidence the checksum will be mangled in a way that makes the packet valid.
probably the simplest checksum to implement if you are not short on bandwidth is just send the data twice. if the 2 copies match then the chances of corruption occurring is fairly small.
dunk.
-
thanks paulstreats
I understand what you are saying with the one way transmission but after doing tests it seems like I get almost no noise at all once the transmitter is on. Meaning once the transmitter has power , the receiver will not output any byte at all - no noise at all ( well ok once in a while I'll get an occasional bad byte) .
Would it be safe to use my packet system and just send each packet twice? (chances are that the receiver will receive at least one of those packets).
As for the checksum business: In my application there are 20 receivers all tuned to the same channel . Each receiver has two addresses. So thats a total of 40 addresses. Meaning if I want to control all 40 addresses at the same time ( which is unlikely in my application) - then I have to send 40 packets. That's half as many packets per second as I get now at 2400 baud. My worry is that if one of the bytes in a packet is corrupted then I'm screwed. (55,56,95) results in a different action then (55,56,59).
If anything I could remove the start bit and have it check for addresses right away. But I guess I can keep it , I mean I already have the system functioning two times as good as I need it . I only need 40 packets a second and I get 80 bytes a second. ( which is good :P )
Also as dunk said I could send the packet twice each time. I guess that could work but it would halve my bandwidth. I might have to do it because I was thinking - if the checksum is NOT manchester encoded(which will usually be the case) then it could screw up the reading of the other bytes that are coming in later. Right?
By the way I'm getting exactly 80% - 240/300 . I guess I could get higher if that damn delay wasn't needed.
I'll up it to 4800 baud and do some tests and see how it goes.
-
Would it be safe to use my packet system and just send each packet twice? (chances are that the receiver will receive at least one of those packets).
that depends on what accuracy you need.
if it's just a simple RC system for example you wouldn't need to worry about the occasional bad packet as the next good packet will arrive a few ms later and overwrite any damage done.
As for the checksum business: In my application there are 20 receivers all tuned to the same channel . Each receiver has two addresses. So thats a total of 40 addresses. Meaning if I want to control all 40 addresses at the same time ( which is unlikely in my application) - then I have to send 40 packets. That's half as many packets per second as I get now at 2400 baud. My worry is that if one of the bytes in a packet is corrupted then I'm screwed. (55,56,95) results in a different action then (55,56,59).
i just want to check something...
you only intend to have 20 receivers powered on at once not the TX modules as well right?
when the TX modules are powered on they "transmit" a "0" as well as a "1". so even when you are not sending something out of one microcontroller's UART, if it's RF module is powered on it is going to interfere with the signal of the others.
if you have 20 of transmitters all powered on at the same time on the same channel you are going to have issues.
if you need multiple transmitters as well you might be better looking into something like the RF modules i'm working with at the moment:
http://media.digikey.com/pdf/Data%20Sheets/Unigen%20PDFs/UGWJ4USHN33A.pdf (http://media.digikey.com/pdf/Data%20Sheets/Unigen%20PDFs/UGWJ4USHN33A.pdf)
far more complicated to use than UART modules but 2-way data flow, huge data rate and over 1000m range...
dunk.
-
20 receivers all controlled from only one transmitter
what about this part of my question
Also as dunk said I could send the packet twice each time. I guess that could work but it would halve my bandwidth. I might have to do it because I was thinking - if the checksum is NOT manchester encoded(which will usually be the case) then it could screw up the reading of the other bytes that are coming in later. Right?
thanks
-
Maybe i need to Manchester Encode the checksum only? I was thinking about it and it seems that a non-manchester checksum would cause trouble. Chances are the sum of two manchester encoded bytes ( address and data) are a non manchester encoded byte.
-
Also as dunk said I could send the packet twice each time. I guess that could work but it would halve my bandwidth. I might have to do it because I was thinking - if the checksum is NOT manchester encoded(which will usually be the case) then it could screw up the reading of the other bytes that are coming in later. Right?
i'm afraid i have no idea what you are talking about.
why would that "screw up the reading of the other bytes that are coming in later"?
with manchester encoding you are sending each bit twice. once normal and once inverted then check that every other bit is the opposite of it's predecessor.
this way each byte takes 16 "normal" bits to transmit.
with your RF modules if you send the byte twice and compare them at the end you achieve the same reliability as manchester encoding. ie, each bit gets transmitted twice and compared. it's just the point at which they are compared that changes.
also a checksum does not guarantee there has been no corruption.
it is possible for 2 completely different packets to have the same checksum.
you just have to do the maths and work out what chance of corruption you find acceptable.
so, yea, i'm going off on a tangent again...
hopefully i hit the answer to your question...
dunk.
-
right now I am not doing manchester encoding, rather I am sending manchester style bytes ( bytes with equal numbers of 1s and 0s that were prerwritten in the code). The checksum would not have an equal number of 1s and 0s and that would cause problems , right?
So I guess my best bet is to send each byte twice and only if they are equal to each other is the reading considered good. I assume I will need some sort of timeout that will stop looking for the second byte after a certain amount of time.
-
are you sure you need to manchester encode at all?
i had presumed the problem was with your UART not with the encoding method all along.
but, yes. sending twice and comparing the results with a suitable timeout will work.
dunk.
-
are you sure you need to manchester encode at all?
Well the Rx has a ranging comparator so I need manchester encode , right?
I'll do tests with no Manchester Encode and see what happens.