serial echo program, dropping characters

zovirl

New Member
My first foray into serial communications on the 14M is going well, but there's one slight problem I can't track down. I'm trying to just make a simple serial "echo" program that will send back whatever I send it, but it occasionally drops characters.
Code:
main:
  serin 1, N2400, b0
  serout 0, N2400, (b0)
  goto main
I'm using the program editor's terminal, and when I sent it this:
Code:
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
...I got back this:
Code:
The quick brown foxjums over the lazy dog.
The quick brown fox jumps over the lazy dog
The quick brown fox jmpsoer the lazy dog.
The quick bow fo jumps over the lazy dog.
The qick brown fox ups over the lazy do.
Almost, but not quite, right. I've made sure the terminal is adding 5ms delay between bytes. I originally was doing this on input 3, but saw that the manual said serin on input 3 was flaky without a diode, so I switched to input 1. I have the 22k/10k resistors on input 1 (same as on the serial programming pin).

I considered the possibility is that there simply isn't enough time between incoming bytes to send outgoing bytes. To test this, I loaded up hyperterminal and tried typing really slowly (2 characters/second). Even with the huge gaps between letters the picaxe still dropped some.

I'm not sure what else it could be. Has anyone else tried something similar and gotten it to work?
 

leftyretro

New Member
Interesting problem. I note that none of the echoed characters are garbled but rather just missing characters. I would suggest putting pause 500 (1/2 second) commands after main, serial in and serial out commands. Then typing slowly from the PC see if there is any case of missing characters. If all is well, then try shortening or eleminating specific pauses to see if the dropped characters return. With software serial subroutines there is a chance that the picaxe program is not ready in time to see a complete well framed character and is dropping it and therefore not avalible to send back to the PC. The hardware assisted serial routines that the 28X and 40X offer may be better at dealing with tight 'loop back' type serial communications. There is a reason that most well written PC serial port drivers utilize buffered input and out streams to help with this kind of timing problem. The Picaxe software serial commands offer no buffering of input and output streams.

So, experimate and see if you can change the symptom or not.
Good luck and keep us posted.

Lefty
 
Last edited:

zovirl

New Member
demonicpicaxeguy said:
how repeatable is the error and is it always all of the same characters that are missing?
Very repeatable, in that I can almost never get a full sentance like "The quick brown fox jumps over the lazy dog." to come through without problems. I haven't noticed any pattern. It isn't always the same letter, or the same position in the sentance. I sent "The quick brown fox jumps over the lazy dog." 3 times, resetting the power the chip before each time. Here are the results:

Code:
The quick brwn fx jumps ovr the lazy do.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumpsover the lzy dog.
I note that none of the echoed characters are garbled but rather just missing characters. I would suggest putting pause 500 (1/2 second) commands after main, serial in and serial out commands. Then typing slowly from the PC see if there is any case of missing characters.
Excellent idea. I also added 2 LEDs so I can see what it is doing. Here's my new program:
Code:
main:
  high 1
  pause 500
  serin 1, N2400, b0
  low 1
  high portc 5
  pause 500
  serout 0, N2400, (b0)
  low portc 5
  pause 500
  goto main
Typing really slowing in hyperterminal, characters were still being dropped but I noticed two different symptoms. Sometimes I would hit a key and the lights wouldn't blink, suggesting that serin missed it. Less often, I would hit a key and the lights would blink but hyperterminal would never show the result, suggesting that serout dropped it.

Hmm, less and less promising. I'd be most interested in knowing if other people have been able to get anything similar working solidly.
 

hippy

Technical Support
Staff member
You could try going back to your original simple program with no LED handling and drop the baud rate. You could also use a "SETFREQ M8" as the first line of code which will make the chip run faster and be less susceptible to dropping characters. That will double the baud rate specified. If it's a problem, change your program to N1200 to keep with the original 2400 baud.

Another ( arguably better ) way to add LED's for monitoring is from the PC Rx In (12V) and PICAXE Tx Out (5V) to 0V via suitable R's. They will light whenever data is sent, even if the PICAXE/PC isn't seeing the data.

A program which just transmits a text string repeatedly will show whether anything is being dropped from the PICAXE to PC. At the moment we cannot be sure where the problem is, whether the PICAXE is missing characters or the PC is not getting them back.
 

zovirl

New Member
Another ( arguably better ) way to add LED's for monitoring is from the PC Rx In (12V) and PICAXE Tx Out (5V) to 0V via suitable R's. They will light whenever data is sent, even if the PICAXE/PC isn't seeing the data.

A program which just transmits a text string repeatedly will show whether anything is being dropped from the PICAXE to PC. At the moment we cannot be sure where the problem is, whether the PICAXE is missing characters or the PC is not getting them back.
Good idea, I went ahead and did this (and went back to the first version of the echo program) The output LED never seemed to miss a character, suggesting that the picaxe was correctly seeing & responding to every character but my computer was missing them. Maybe my serial port needs a max232 to bring the voltages up?

2 odd things about this result:
1) it seems to contradict my previous experiment's result, where sometimes the chip never left the serin state.
2) Oddly I've never had a problem programming the picaxe. Does the programmer do error correction?

demonicpicaxeguy asked about the wiring. Power is from a 16v wall wart running through a 7805, 100uf on the supply side, 10uf on the output side (basically, the final circuit from this page: http://www.sparkfun.com/commerce/present.php?p=BEE-1-PowerSupply). I've measured with my multimeter and it is constant 5.08v. I don't have an oscilloscope so I can't check much more than that.

The serial connection is just a serial cable with one end cut off. I stripped & tinned the 3 wires and stuck them into the breadboard. The cable is zip-tied to the breadboard's baseplate to remove stress from the individual wires. The serial in line is switched between legs 2 & 6 of the picaxe with a SPDT switch.

Wires all seem solid, and I've never had a problem programming, so unless the programmer does some error correction I think the problem must lie elsewhere.
 

Technical

Technical Support
Staff member
The serial in line is switched between legs 2 & 6 of the picaxe with a SPDT switch.
So do you have 2 lots of 10k/22k with switch before them , or one set of resistors with switch after it. If it's the second case then you are leaving serrxd pin floating when the switch is moved across, which is not allowed and will give errors.

As Hippy suggested earlier, the obvious test for the PC connection is just to serout without serin:

Code:
main:
  pause 500
  serout 0, N2400, ("the quick brown fox",CR,LF)
goto main
 
Last edited:

Brietech

Senior Member
It's likely not the problem, but you could also check out what your computer's serial port "buffer" is set at. That has given me problems before, where I basically just overflow the buffer and data gets dropped. Maybe you could run a test between two picaxes, and see if the problem still occurs?
 

moxhamj

New Member
Whether it turns out to be PC to picaxe or picaxe to PC it might be worth adding error checking and qualifyer bytes. I tend to use packets with a qualifier at the beginning (usually "ABC") then a number of bytes then a 2 byte checksum which is the sum of the bytes. Discard any packet where the data is corrupted.

Also you might want to look at reading the data into a program rather than hyperterminal. I have used VB6 and VB.net and both can handle serial comms though the syntax is quite different with the newer VB.net. However, all the .net programs are available free which means it is worth learning the new commands. Serial comms is about a 20 line vb.net program.

Where are you heading with this project? - it may be that one or more people on this forum have some complete code already written.
 

zovirl

New Member
So do you have 2 lots of 10k/22k with switch before them , or one set of resistors with switch after it. If it's the second case then you are leaving serrxd pin floating when the switch is moved across, which is not allowed and will give errors.
Correct, I have two 10k/22k pairs, one for each picaxe pin, so neither pin is floating.

I tried the serin-only & serout-only suggestion. I used the dirt-simple serout program suggested above:
Code:
main:
  serout 0, N2400, ("The quick brown fox jumps over the lazy dog.",CR,LF)
  goto main
Watching with the programmer editor's terminal window, it never seemed to miss a letter.

Here's the serin program:
Code:
main:
  serin 1, N2400, b0, b1, b2
  if b0 != 97 then die  ' a
  if b1 != 98 then die  ' b
  if b2 != 99 then die  ' c 
  goto main

die:
  high 1  ' turn on LED
  stop
I used the programmer editor's terminal to send 'abc' several times. I would die after several iterations. Once, I was able to send 9 copies before the LED came on. One time, it died after only 3 copies of 'abc' were sent.

So, this suggests that serin (sending from PC to picaxe) is the problem. I find it odd that my experiments keep contradicting one another. I'm not sure what to make of that.

brietech said:
It's likely not the problem, but you could also check out what your computer's serial port "buffer" is set at. That has given me problems before, where I basically just overflow the buffer and data gets dropped.
Good idea. I went into device manager & found the advanced settings for com2. Oddly, the dialog suggested turning down the size of the buffer to correct connection problems. I lowered it, tested, then turned off the buffer completely & tested. It *might* go longer without messing up on the serin program, although maybe not. It still messes up, though.

Dr_Acula said:
it might be worth adding error checking and qualifyer bytes.
Yes, I saw how your mesh network picaxe code used packets & checksums. I would expect to need this for wireless links, but I'm surprised that I'd need it for a serial cable. Does anyone happen to know if the programmer uses error correction? Is it normal to need error correction for serial cable links?

Dr_Acula said:
Also you might want to look at reading the data into a program rather than hyperterminal. I have used VB6 and VB.net and both can handle serial comms though the syntax is quite different with the newer VB.net. However, all the .net programs are available free which means it is worth learning the new commands. Serial comms is about a 20 line vb.net program.
Yep, so far I've tried the program editor's terminal, hyperterminal, and Python. Haven't tried VB.net yet, but it doesn't seem neccessary since I've tried 3 other methods.

Dr_Acula said:
Where are you heading with this project? - it may be that one or more people on this forum have some complete code already written.
What I'd really like to do is something like this: http://www.petesworld.demon.co.uk/homebrew/PIC/simplergb/index.htm. Sadly, though, I already asked about the feasibility of doing that (http://www.picaxeforum.co.uk/showthread.php?t=7671) and it sounds like I really need either one of the X1 chips or a bare PIC. I can't decide which route I want to take (I love the simplicity of programming the picaxe, but I'd also prefer an 8-pin chip and there's no 08X1). So at the moment I'm just playing with my 14M, seeing what I can do with it.
 

moxhamj

New Member
If the problem is PC to the picaxe, and it persists with several different pieces of software, then this may suggest some sort of hardware problem. Maybe the RS232 from the PC is not swinging +12V to -12V. Just check it is sitting at -11 to -12V when it is not sending anything.

Once when I just couldn't get anything to work I resorted to sending the data at 300 baud and looking at the trace on a cro (free software CRO like wavetools). I got quite good at reading characters off a waveform.

Just to check - do you have 0.1uF across the picaxe?
 

moxhamj

New Member
Another test is a loopback test - connect pin 2 and 3 on the serial of the PC and leave the picaxe out. Then try hyperterminal at various baud rates.

Then maybe a loopback test but via a couple of HC04 inverters if you have them. Use the 10k/22k circuit going into the first inverter. The first inverter inverts the signal then the second inverts it back. The output is now 0V/5V instead of -12/+12V but a PC RS232 input should still be happy with this as an input.

Then if all that works, check two picaxes can talk to each other.
 

zovirl

New Member
If the problem is PC to the picaxe, and it persists with several different pieces of software, then this may suggest some sort of hardware problem. Maybe the RS232 from the PC is not swinging +12V to -12V. Just check it is sitting at -11 to -12V when it is not sending anything.

Once when I just couldn't get anything to work I resorted to sending the data at 300 baud and looking at the trace on a cro (free software CRO like wavetools). I got quite good at reading characters off a waveform.

Just to check - do you have 0.1uF across the picaxe?
Yep, I checked the serial when it was at idle, and it was around -11 or -12. What do you mean 0.1uF across the picaxe? Between which pins?

I don't have an oscilloscope, or else I would have already hooked it up to troubleshoot this :) Am I right in thinking wavetools uses my computer's line-in? So I'd just need a circuit to get the voltages to the right level?

I have a 2nd picaxe but not a 2nd socket. Perhaps it is time for another trip to the store...
 

moxhamj

New Member
-11 to -12V is good.
0.1 across the picaxe means across the power supply pins. It acts like a filter.
Wavetools is free and it uses the computer's line-in. You wouldn't need any circuit to get the voltages to the right level - just adjust the volume in windows sound settings.
Before Manuka gets in ahead of me, I'd suggest you get a proto board. Small ones are only $7 or so.
I presume you know the RS232 protocol is -12V to +12V, and voltages +/-3V are invalid. PCs follow the correct protocol for outputting data. A PC will also be happy with -12v/+12V as an input. However, PCs also break the rules by allowing 0V/+5V as valid input voltages. So you can cheat a bit by converting the RS232 output to 0V/5V with the 22k/10k circuit, run it through standard digital (LS/HC/cmos) circuits and then back into the PC.
Did the loopback test work?
 
Last edited:

inglewoodpete

Senior Member
The 100n capacitor is not stictly necessary, although I always mount 1 as close as I can to the PICAXE as insurance. The think forum members may be clutching at straws. A 100n capacitor can smooth higher frequency (shorter duration) transients on the power line.

My opinion of the problem is that the PICAXE and PC both have a slightly different view of what the correct data clock speed is. I think there is a way of fine tuning the PICAXE clock, which in turn will alter the transmit and receive data rate slightly. A search of the forums or documentation should help here.
 

moxhamj

New Member
Re the 0.1, running a picaxe producing a 1khz waveform into a cro with the picaxe powered by a computer PC, the waveform is much smoother with the 0.1uF. Maybe this isn't relevant if the power supply here is not a PC 5V, but the 0.1 cap does make a huge difference if the power supply is noisy. Is it noisy? We don't know, but it is fascinating to build a microphone amplifier circuit then go round just touching wires and listening. The body picks up lots of mains hum and lots of hash from flouro lights and will re-radiate it to any nearby wires. Every wire is an antenna. A power supply wire going to a picaxe, even if only 10cm long, is still an antenna. It is also a resistor - a fraction of an ohm. This resistor and the 0.1uF cap are a low pass filter - they filter any RF hash etc that might be out there.

I've been through all this comms stuff before - it is very frustrating. Days of work sometimes. Need to break down each and every part of the problem to isolate exactly where it is happening.

We have a loopback test working.

If it is a clock problem then try 300 baud as the timing error will be less.

Do you have a 74HC04 or any sort of digital chips on hand that can be used to create a buffer/loopback test. RS232 => 22k/10k => HC04 (2 in series with indicator leds) => back to PC. Any power supply hash problems will show up here - this helps distinguish between timing problems and power supply noise problems.

If you have 2 14Ms, set one up to transmit a character every second and set the second one up to flash a led when it gets that character. Check every one is going through. If that works, then tap into the line and see if the PC can detect every character as well.

If you have 2 14Ms, also try sending the data from the PC to 22k/10k and then to the inputs of both chips. Flash a led when a character arrives. Check if missing characters are missed on both 14Ms at the same time.
 

hippy

Technical Support
Staff member
Another thing to try is a terminal emulator which shows the hexadecimal values of data being received. Some terminals may drop non-printable characters which are caused by baud rate differences and so on. Luckily, I have one that does that ...

http://homepage.ntlworld.com/the.happy.hippy/picaxe/aiterm.zip

If it's an incoming voltage problem ( which the voltages don't indicate it is ) it is possible to lower the 22K resistor value, but that should be done with caution as it can take the input voltage out of spec and potentialy damage the PICAXE.

The other possibility is a problem with the Firmware although it's hard to see how this could be with the test program used. As suggested, dropping to 600 baud would be something definitely worth trying, also going up to 4800 to see if things get worse.
 

zovirl

New Member
I tried N300, and got "Error: Unknown symbol N300." Maybe a bug? I tried N600, it still misses characters on serin. It didn't seem to be any better, seemed to be missing them at about the same rate.

I tried hooking this up to a 2nd computer. Serout (picaxe to PC) still worked flawlessly. Serin (PC to picaxe) still dropped characters.

I tried the port test (under view->options). The first voltage measured was -0.57v, the 2nd voltage measured was 5.7v, both of which seem correct.

Since I'm just getting back into electronics I don't have a full bin of spare parts yet, so I can't try any fun tests with 74HC04's. It is a bit of a shock after playing in a fully-stocked electronics lab in college :)

This is 14M firmware version 9.C. Is that the latest firmware? I don't suppose anyone else can try this program and confirm that it works on your chip?

Code:
main:
  serin 1, N2400, b0, b1, b2
  if b0 != 97 then die  ' a
  if b1 != 98 then die  ' b
  if b2 != 99 then die  ' c 
  goto main

die:
  high 1  ' turn on LED
  stop
You send it 'abc' over and over, and the LED should never come on. On my chip, I've never sent more than about 10 copies of 'abc' before the light comes on.
 

moxhamj

New Member
Different computers and same fault, fault repeatable at slower baud rates, fault only happening from PC to picaxe, voltages all correct, power supply almost certainly fine, loopback works fine. Hmm.

The only thing different to my setup is I am using 08Ms and you are using 14Ms. I hope this isn't a firmware bug. Do you have an 08M?
 

hippy

Technical Support
Staff member
@ zovirl : N300 only existed I think for Firmware 9.A and it should have been N4800 which is now supported. There's only a limited number of baud rates each PICAXE handles and it's either N300 or N4800.

@ Dr_Acula : I've not had problems with any other PICAXE's when sending with large gaps between characters but don't have a 14M to try with.

@ All : A firmware problem it could be, but we haven't narrowed down other possibilities. The best suggestions are, as per Dr_Acula, for zovirl to try the same with any other PICAXE, someone else to attempt to replicate the problem with a 14M.
 

zovirl

New Member
Different computers and same fault, fault repeatable at slower baud rates, fault only happening from PC to picaxe, voltages all correct, power supply almost certainly fine, loopback works fine. Hmm.

The only thing different to my setup is I am using 08Ms and you are using 14Ms. I hope this isn't a firmware bug. Do you have an 08M?
Nope, no 08M. These two 14M's are my first picaxe chips :)

I'll try adding the 2nd 14M to my breadboard so I can try getting them to talk to each other. In the meantime, I'd definitely appreciate it if someone else could try my program with a 14M, preferably 9.C firmware.
 

moxhamj

New Member
Have just done some experiments and have replicated the fault.

1) Serin 1 on a 14M - I can't get this to work as pin1 is an output on a 14M. BUT I changed serin 1 to serin 4 as 4 is an input on an 08/08M and an input on a 14M as well.

2) Tests with an 08 and a 14M suggest there may be a 14M bug. Using serin to pin4 it works fine with the 08 and does not work with the 14M. Was outputting a led on pin 2 and input to pin4 so the pinouts were the same and can do a hotswap of the chips while sending data out from the PC every 4 seconds using a small VB program. Maybe someone else can replicate this and if so then maybe take it further. Meanwhile, perhaps get some 08s or 08Ms.

VB was sending abc123 and code is:

main:serin 4,N2400,("abc123")
high 2
pause 1000
low 2
goto main
 
Last edited:

Technical

Technical Support
Staff member
You can use input 1 on both 08M and 14M with serin... 14M's have separate input 1 and output 1.

We have just tried Dr_Aculas program with a 14M version C and it works fine - our test jig uses input 1 as zovirl is using. What version chip are you using?

Code:
main:
serin 1,N2400,("abc123")
high 2
pause 1000
low 2
goto main
 
Last edited:

Technical

Technical Support
Staff member
We've now tested this program:

Code:
main:
  serin 1, N2400, b0, b1, b2
  if b0 != 97 then die  ' a
  if b1 != 98 then die  ' b
  if b2 != 99 then die  ' c 
  goto main

die:
  high 1  ' turn on LED
  stop
If you type any number of abc into the serial terminal with the '5ms between bytes' option enabled and send them it works fine.

However if you have a long string of abc's without the 5ms delay option then it will stop. However this is expected behaviour - as there is no qualifier used eventually somes bits of the long string will be received during the 'if' statements. The next serin will therefore be corrupt and cause the program to stop. This is quite normal, to overcome the issue use delays between bytes or use a qualifier in the serin command.
 

moxhamj

New Member
14M chip is v 9.A

Results are a bit strange - for 1/2 an hour I have been getting the same problem as zovirl, and then suddenly it is working on the 14M and nothing has changed.

I have tried to reduce this to a minimalist setup. An 08 is sending out this program with 0V on physical legs 8 and 2 and 5V on leg 1. 0.1uF across chips.
main:
serout 2,N2400,("abc123")
pause 4000
goto main

And the data is going to this program running on either an 08, 08M or 14M
main:serin 4,N2400,("abc123")
high 2
pause 1000
low 2
goto main

As before, for 1/2 an hour I could not get the 14M to respond.

But suddenly it is working, and it is working on all pins - pin 0 to pin4 inputs.

I am baffled by this. The only thing that changed when it started working was I downloaded Technical's suggestion of using pin 1 input instead of pin 4. Maybe this kicked it into working on all the other pins. Maybe the chip warmed up a bit and a timing constant changed (it is 6 degrees C at the moment). Or maybe my wiring was dodgy?! Or maybe it was the bytes getting out of sync.

Addit: - have just swapped in a brand new 14M straight out of the tube and that works fine, so I'm going to go for the dodgy wiring explanation at this stage!

Zovirl - can you set up one 14M as an output chip and one as an input chip with the programs above and see if it works? Try inputting to each of pins 0-4 and change the code accordingly.
 
Last edited:

zovirl

New Member
My 14M's are both 9.C.

I hooked the two 14M's together. One sends 'abc' over & over (with pauses). The other expects to receive 'abc' and gives a short blink (on an LED) if it gets 'abc', long blink if it sees something else. This works flawlessly.

I replace the "sender" by my computer and it was flakey, as before. 1 'abc' out of every 10 to 20 isn't received correctly by the 14M. Yes, I definitely have the '5ms delay' checked in the programmer. I've also tried 100ms delays using Python.

Technical, does the programmer do error correction as it is transferring my code to the picaxe? One thing that puzzles me is that my serial transmissions seem to have problems, but the programmer doesn't seem to have any trouble programming the picaxe.
 

hippy

Technical Support
Staff member
It does sound like the 14M is off the hook blame wise and the problem rests with your PC to PICAXE interface.

The Programming Editor doesn't do error correction but does check that what was sent was received and acknowledged correctly.
 

zovirl

New Member
Yep, it looks like the 14M is working correctly, so at least I'm closer to having the whole system working.

Anyone have a theory for why the programmer isn't hitting these errors? Is there some simple software trick I'm missing?
 

moxhamj

New Member
If everything works from the computer except one in twenty messages don't get through, then this would be a case for adding error correction. Send a preamble "abc" and then do a checksum at the end of the packet. Keep the packets the same length. Maybe we will never know where the fault is, but if there is error correction it won't matter.
 
Top