Cant read PIC usart data

To: alt.electronics,sci.elect Compare very carefully the waveforms going into your computer when you connect it directly vs. through the radio transmitter.

To: alt.electronics,sci.elect Mark,

What is the EasyRadio ? Is it designed to handle NRZ data ? Many radio links use an adaptive style data slicer that requires some preamble to set it up and usually the data needs to be DC balanced (long runs of "1" or "0" cause errors) so some form of Manchester coding is usually utilized.

Can you capture the received data and analyze it for missing bits ?

Kind Regards

David

----------------------------------------------------------- ORBIT COMMUNICATIONS Pty Ltd - Wireless Solutions that Work (Telemetry, Control, Monitoring, Security, HVAC ...) A.C.N. 107 441 869

Website :

Serial port on unix is not straight forward. Unix (linux included) serial port drivers assumes that the serial port is attached to a terminal and so the device drivers does all sort of "smart" things like echo, remote echo, readline etc. You need to bend over backwards to get it to work as a "simple" serial port.

To get/set serial port parameters, use stty:

stty -F /dev/ttyS0

I'd recommend using a terminal program like minicom instead of directly reading /dev/ttyS0 for testing.

To: alt.electronics,sci.elect

Mark Fortune =E5=86=99=E9=81=93=EF=BC=9A

You may use the software "minicom" to read data from PC's serial port.And you can set the serial port's status,including band,hardware flow control,and so on by this software. Maybe this will help you.

To: alt.electronics,sci.elect Mark Fortune wrote: [tales of woe with radio modules snipped]

Use a proper serial terminal program, there are many to choose from. I use this script in kermit:

set modem type none ; There is no modem set line /dev/ttyS0 ; Specify device name set carrier-watch off ; If DTR and CD are not cross-connected set speed 19200 ; Or other desired speed set flow none ; If you can't use RTS/CTS set parity none ; (or "mark" or "space", if necessary) set stop-bits 1 ; (rarely necessary) connect ; Enter Connect (terminal) state

Save it as myname.foo and then: $kermit -y myname.foo

Tim

^^^^^^^^^^^^

^^^^^^^^^^^^^^^^^

The first thing I'd suspect is mismatched baud rates.

Good Luck! Rich

the easyradio handles preamble and manchester encding automatically. You basically feed data from the usart into the transmitter, and it transmits when its buffer reaches 128 bytes or detects a 2 byte gap (ie no data). it defaults to 19200baud but this can apparently be programmed. i'm using the pic usart set to 19200 baud. it then automatically sends the preamble, which the reciever automatically locks onto, and the data is transmitted using manchester coding (according to the manual anyway, I dont admit to knowing exactly how all this works). My scope is fairly old, so I have some difficulty in capturing the data with any accuracy, but it certainly appears that the data streaming out of the reciever is the same as the data going into the transmitter.

Mark

How much of a difference does it make if the baud rate is off by +-50? the problem here is the usart is clocked using the PICs internal oscilator, which tends to drift with temperature variations.

OK thanks, i've tried minicom now and i'm getting garbage through - but at least it's a lot more than I was getting before. I think I need to invert the output from the radio to stop it being garbage. Some experimentation is needed now.

Thanks Mark

Yes and no, I did connect the TTL UART output from the PIC into the MAX232 - thus bypassing the radio link using just the TX and ground, but on the initial runs I got absolutely nothing on the PC.. Now in minicom I am getting (garbage) data through, but it's _exactly_ the same data - garbage or not - weather it's direct from the PIC or via the radio. Thus my suspicion is that the radio is transfering the data in one piece without any corruption.

See above

I am going to try inverting the signal, i'm just looking through my parts now to see if I have something I can bodge together (unfortunately last time I ordered some hex inverters I didnt realise they were surface mount - doh)

To: alt.electronics,sci.elect Mark,

Did you mean in your earlier posting that you attached the TTL UART output from the PIC into the MAX232 converter (bypassing the radio link) and the data displayed on the PC fine ? Was this using TX and ground connection only ?

If not, this is something you could try to eliminate the PIC,Data and PC terminal program, leaving just the radio link to investigate.

If you have done this then the terminal program is fine.

If you have an old scope and cannot capture a packet then send a single character (say an "A") in a loop as quickly as the radio link can handle.

This will enable the scope to trigger and the display will be steady enough to study the received data.

Alternately, if you just want to "suck it and see" then write a small routine to bit bash a character out the serial port pin. This will enable you to change the polarity of the data sent and see if the data now gets through to the PC. If it does then you need to either bit bash all your transmitted data or place an inverter between RXD on receiver and the MAX232.

Kind Regards

David

----------------------------------------------------------- ORBIT COMMUNICATIONS Pty Ltd - Wireless Solutions that Work (Telemetry, Control, Monitoring, Security, HVAC ...) A.C.N. 107 441 869

Website :

To: alt.electronics,sci.elect Mark,

If you have not been able to get data to the PC via Micro UART to MAX232 then inverting it won't help.

The data from the micro should already be the correct polarity.

From what you say, it looks more likely there is a problem with the Data itself (Check Baud rate and receive mode etc on the terminal program). Also check your program to ensure you have selected the correct Baud rate divisor (BRGH and SPRG regs). Particularly ensure these values are correct for the given crystal you are using on the PIC. (I am assuming the oscillator circuit on your PIC is working correctly).

Kind Regards

David

----------------------------------------------------------- ORBIT COMMUNICATIONS Pty Ltd - Wireless Solutions that Work (Telemetry, Control, Monitoring, Security, HVAC ...) A.C.N. 107 441 869

Website :

If the baud is off by more than

If so,I think that you could use low baud rate,like 4800,2400,1200.This may make it on the rails.

I'm sorry that my english is not good enough.I hope that these will help you.

A difference of +/-50 (if that's really what it is) is 0.2% which is well within the recommended +/-1.5%.

I once did a bit-banged UART (transmit only) on a 16C770 at 9600 baud using the internal RC oscillator. Looking at the data sheet it wasn't guaranteed to meet the spec even at room temperature but in practice it worked OK. We got a failure rate of a few percent at end-of-line test (this was a very low cost product and the UART was only used for calibration so this was deemed acceptable).

Do you have any way of *accurately* measuring the bit-times at the PC RX input pin?

Maybe you should bite the bullet and buy a 50 cent crystal. I would recommend a 7.3728mhz, This will be easier than a 10mhz, or other value. It divides exactly to give a serial UART its charm.

If you send a single character '0xF0' to the PC from the micro, you can see what the PC shows.

(11110000)

If you you see more than one charcter coming out, then speed up the PIC. you then can draw out in binary the bits you get out, and use this to tune your speed.

Then only other way is a digital storage scope.

I would also suggest to try sending one character at a time. This will be easier to debug.

Another possible trick is to send hex AA AA AA AA AA AA AA forever out of the micro and use a frequency counter. However you need to remember to make an allowance for the stop bit. So 9600bps baud should show up as 96,000hz. This is corny, but some multimeters measure frequency.

if you can wire it to one of the other input pins I can get better than microsecond timings in dos (from the timer chip) or linux (gettimeofday)

Bye. Jasen

To: alt.electronics,sci.elect

There will be no PICs in the near future . ARM cpu's will kill everything made .

Computers , when they change , destroy hardware in the 100's Millions of $$ and RIF millions of jobs !

Just ask Sun microsystems in 2001 !! It took Nasdaq from 5000 to

And its so easy to improve hardware and software ! but govts have stiff penalties for improving . But s/w is slow to change for they have obtuse hardware ( PC ) , but when a new CPU comes along that nix's need for North/South bridge , FDC , HDC ....

PDAs have an ARM CPU that burns 2 watts and has all these chips built in . It can do giga bytes , and 100's of MegaFlops , which means , some one will find it much easier to create a free OpSys on the easier h/w .

Linux is actually tied to the PC , it can't migrate to PDA , for it will be obsoleted by the FREE OpSys that has not the problems with simple stuff like Files/Folders ( Linux cant do this stuff )

I will do a free OpSys . It manages all objects /Files/folders . It will be totally integrated . No separate HLL to load , you can create assmbly code from high level , in place , and run it imediately .

Mark Fortune wrote: