#28044 Laser range finder: bad serial transmission
JROCHET
Posts: 3
Good evening
I've recently purchased a 28044 LFR from parallax in order to integrate this into one of our device that is currently under development. Basically , we planned to interface it on an arduino and eventually through labview thanks to Linx.
However I already have some issues with the code that is provided by Parallax with the Arduino IDE.
So basic stuff, I'm using a venerable Uno and changed the Pins in the code to match my layout (Rx and Tx are on digital 00 and digital 01 instead of 10 and 11).
I've seen the led on the LFR going red and the laser pointer bursting. Some correct data is then sent on the serial port but then things are going bad and after the first correct measurement, I'm receiving random characters.
So basically, the soft seems OK everywhere but I have a bad serial transmission, some parasite are perceivied as bits and its going to be a mess.
Now, this also occures when the Sin and Sout are directly plugged into the arduino ( supply is brought through another connector).
I've supplied the arduino with an external power supply (9V 400 mA) so there should be far enough for the LFR.
I've seen on the schematics that there are already 4,7k pull up resistors so I have no idea left on how to increase to connection quality.
Any idea?
Thanks by advance for your ideas
I've recently purchased a 28044 LFR from parallax in order to integrate this into one of our device that is currently under development. Basically , we planned to interface it on an arduino and eventually through labview thanks to Linx.
However I already have some issues with the code that is provided by Parallax with the Arduino IDE.
So basic stuff, I'm using a venerable Uno and changed the Pins in the code to match my layout (Rx and Tx are on digital 00 and digital 01 instead of 10 and 11).
I've seen the led on the LFR going red and the laser pointer bursting. Some correct data is then sent on the serial port but then things are going bad and after the first correct measurement, I'm receiving random characters.
So basically, the soft seems OK everywhere but I have a bad serial transmission, some parasite are perceivied as bits and its going to be a mess.
Now, this also occures when the Sin and Sout are directly plugged into the arduino ( supply is brought through another connector).
I've supplied the arduino with an external power supply (9V 400 mA) so there should be far enough for the LFR.
I've seen on the schematics that there are already 4,7k pull up resistors so I have no idea left on how to increase to connection quality.
Any idea?
Thanks by advance for your ideas
Comments
Do you have the grounds connected?
Are you using a software UART on the Arduino? (IIRC you would need to in order to use pins 10 and 11 rather than 0 and 1).
Have you tried communicating the the LRF with pins 0 and 1? If so how did it work?
What baud are you using?
If you attach your code (you might have to zip it) I can try to replicate the problem.
One other question, what is the frequency of the crystal you're using (on the Arduino)?
I use the 5V and gnd from the arduino and the gnd is common with my power supply
I use this code located here:
http://www.parallax.com/downloads/laser-range-finder-arduino-example-program
with only two modifications:
10-> 00 and 11-> 01 since I'm using an arduino Uno
From what I read in the arduino code, the serial is 9600 8N1, usual stuff.
The crystal of the arduino is 16 MHz.
I've just inserted the serial pins of the LFR inside the connectors of the arduino and I supply the LFR with another connector linked to 5V pin and gnd pin of he arduino.
On the schematics of the uno: http://arduino.cc/en/uploads/Main/Arduino_Uno_Rev3-schematic.pdf
Pins 10 and 11 are used for the crystal on the ATmega328P. The other uc, the ATmega16U2 is used for usb communication
I assume the communication is I²C but the levels should be compatible the ones of the LFR.
The point is that if I run the arduino, I manage to get some data, generally the first set of data correctly. But after a while ( some seconds), some random characters are appearing on the serial port (monitored through the utility included within the arduino IDE). No way to find back the chain 'D=xxxx mm' even though the laser of the LFR is blinking sometimes. Even that is stopping at some point.
It look likes something is perturbarting the line.
Here is typically what I get:
I understand what you're saying now. You're misunderstanding what is meant by a pin number. It's more of a "port" number. Physical pins are numbered starting with #1. Ports are numbered starting with #0. There is no way of knowing what pin is used by which port without being told (by schematic, datasheet, etc.). I'm not sure if "port" is the correct term but that's what I'll use for now.
Ports are commonly called "pins" which can be confusing. So pins 10 and 11 are really ports 10 and 11 (though I'm not sure they're really called ports) and these ports use the physical pins #16 and #17 on the DIP chip (they can be different physical pin numbers based on the chip package).
Ports 0 and 1 are using to communicate with the PC. Your changes to the program is interfering with the hardware UART (on ports 0 and 1). The program is attempting to communicate with the LRF and the PC with the same pins.
Switch to using ports 10 and 11 and see how it goes. I marked these ports and the physical pins (16 and 17) on this picture.
Check to see where pins 16 and 17 lead in the schematic you linked to. You'll see they lead to a head with the numbers 10 and 11 next to it.
You're not the first to be confused by pin numbers on circuit boards. I've seen similar questions from engineers.
Indeed, I thought that since it was communicating through a serial communication, it has to be on the RX/TX pair.
But it uses the software serial library and create a software serial port on 10 and 11 in order to avoid messing around with the physical serial port.
Going on the pins 10 and 11, the communication is flawless.
Thanks a lot for your time, it save my week
Very good. Thanks for letting us know it's working.