With cable directly connect to a RS232 serial port, I got perfect data transmission.
However, when I switch to SMIRF v2.0, the data is highly corrupted, and the transmission is very unstable.
Anyone has an idea of the cause(s) ?
thanks
The question is how are you switching?
The remote unit - is it connected to an Microcontroller? Is it connected to a MAX232 in any way (it shouldn’t be)?
-Nathan
Well, I wrote my own code for PIC microcontroller for serial transmission (so I can use any pin as Tx and Rx → thus virtually have multiple UART ports).
I have my serial cable connected to a RS232 and the remote wireless directly on 2 other pins. They are being connected to my computer on COM2 and COM4 respectively. (for both, I am sending out Asynchronously using Tx and Rx pins only)
With the same code structure, I send perfectly via RS232
however, when I send the data via SMIRF, it is not always sending…
and the received data has a lot of mistakes (I really mean A LOT)
I even turn off my 2.4Ghz wireless phone and my 2.4Ghz router…
no difference…
I test all speeds…samething… I successfuly scan and configure using your driver…
Let me know what is wrong!!!
problem is not in transmission.
Can u give an example of the errors with ASCII sent, ASCII received. It could be a problem with ur bit banged code, or perhaps a problem with smirf…
Problem is data sent from the base unit will have 16bit CRC checking, so its not a sending problem as u are getting data.
But we need to look at a string of 5 or more characters to see if there is some problem, perhaps a shift on the reading of bits.
Ok, I programmed to send HELLO WORLD! to PC via SMIRF 2.0.
The actual signal I am getting looks like that:
¡KOJA¡KHED!HELLO eo=I1A¡KHELLDLLO WORWORLD!HETtHELLO Weo=I1RLD!HELLO ¡KHELLO WORLHELLA¡KHELLO WOO WORLD!HEOJA¡KHELLO HELLO WORLDo=I1¡KHELL?¡KHELLO WOORLD!HEI1¡KHELLO ELLO WORLo=I1¡KHELLTtHELLO WO=?WORLD!H*?¡KHELLO DLLO WORLDo=I1¡KHELLTtHELLO WORO WORLD!HEHELLO LLO WORLD=I1¡KHELLEHELLO WOR?WORLD!HE¡KHELLO LO WORLI1¡KHELLELLO WO!LDORtE?LD!=I1LD!HELLOeo
(It should display HELLO WORLD!HELLO WORLD!HELLO WORLD!..)
Beside, I resolve the problem why SMIRF is not always sending (I just sent the Stop bit, but never keep it at 1 after the Stop bit).
Please help me to find the problem. I believe this will definitively help others.
Your response is very cryptic -
Beside, I resolve the problem why SMIRF is not always sending (I just sent the Stop bit, but never keep it at 1 after the Stop bit).
What does this mean? Something to do with your software serial routines?
Always be sure you do not have a MAX232 driver on the line. The MAX232 will try to drive the RX pin on the PIC. If the SMiRF is attached, it will try to compete and you will have lots of problems.
It looks as if the SMiRF is communicating but your timing may be off slightly. Double check you bit banging routines.
Also, you may want to insert a delay between sent characters - you may be cutting the stop bit too short.
An explanation why your serial cable works so well : the serial port on your computer can have very sloppy tolerances meaning, you can be off as much as 5-10% on the timing and the computer will interpret the serial characters correctly. The SMiRF does not have such tolerances, your timing must be right on (+/-1%).
-Nathan
hi
l am Wri tting from my PDA so please bear with me!
Can u display the hex codes For that text String as some Of the charaChters ane not unicocle compiant. so i cannot translate into binary .
Regards
Martyn
Actually, the remote control is stop sending at some instances for few seconds…
I just improve the stability by improving my code. But didn’t solve completely.
After adding some short delay between each sending sequence, the output is indeed better.
I don’t really think my delay code has problem, as I am programming in assembly language and I did count the number of cycles to write my delay code. I will make the delay exactly 104.2us to see if the delay is really the problem (I was giving a delay of 103us, and i briefly count the execution routine as 1-2us for a total in the range of 104-105us)
I actually hope that SparkFun post some testing code for popular microcontrollers…
What I am getting now looks like this:
HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!@LLO WORLD!HELoLLO uDO WO!HELWORLDHELLOLD!LLO WD!HEWORLHELLoORLD!ELLO LO WOHEtWORLHELLORLD!LLO WHu WORHELyORLDELLOuO W!HELHELLD!LLO D!y WOHEyORLELLLD!uO WHRHELLDLLOD!y WHEORELLDLO ttWOEuLoLLDLO y! WOHENRLyLLuD!O WOELeLDuuO !H WORHELLO WORLD!HELLO WORL
Very annoying, the remote unit does still stop sending signals at some instances (can be upto 10 seconds)… But its light does blink when I send signal to it from the base unit.
Please note that for the above signal, I have a 5us delay in between each transmission (of 8 bits). Less than that, it is still outputing pretty bad data…
Hello,
Please be aware - serial transmissions are 10 bits - 8 + 1 start, 1 stop. You indicate 5us between, but this should be more like 104-110us. Please try to use a hardware UART to get the timing right.
It seems to me like the link is operational - but there is some corruption as time goes on. This indicates to me that the serial timing is slewing on your controller.
Using RF, packets will be lost. The SMiRF handles these by re-transmitting after a timeout period. Buffers on both ends will help prevent data loss but if the buffers fill because of lost packets, overall data will be lost. Because of this, it is not recommeneded to send a constant stream of data every 104.16us. Send upto 60 characters at a time, but allow some time (100-200ms) for the buffers to clear themselves.
-Nathan
Hi Nathan
I do sent 1 start bit + 8 data bits + 1 stop bits (sorry for the mistake in my previous message), then I pause 5us; and after that 10bits againt, then stop another 5us.
I believe you just hit the heart of the problem, as I am keep sending no stop (maybe with a delay of 50ms at max), so the buffers don’t have the time to clear themselves (perhaps this is the reason why the remote stop transmitting after a while, at constant intervals)
Think about it, the transmission is always good, then corrupted data start to pump in, then the remote stop to send. Then restart sending good data, and so on… Should be the buffers as you mentioned.
I will definitively use the hardware UART to test it again and leave time for clearing the buffers.
Thanks a lot, very helpful.