The bit I still don't understand is the impact of the Arduino pullup being disabled !
Sure- with that enabled, the low is probably about 1.8V (due to the voltage divider effect of that ~20K pullup). Sure, that's not low enough to be read as low.
However, with the Arduino internal pullup disabled, there should be no reason for the low voltage to be above ~300mV, and that would certainly read as low.
I'm wondering if the Arduino needs some extra code to "really" disable that internal pullup. Maybe something else needs writing to the pin register, or some global control.
Has anyone with this issue actually checked that the Arduino is definitely NOT pulling up the input for the duration that it's expecting some serial input ?
Another question for clarity-- is the Arduino in use 5V or 3.3V IO level ?
Don't forget that the Propeller Tx pin is also having to pull down 3.3v to 0v through a 100k resistor on the DHB-10 board which is not much compared to the 20k pull up resistor on the Arduino Rx pin.
Don't forget that the Propeller Tx pin is also having to pull down 3.3v to 0v through a 100k resistor on the DHB-10 board which is not much compared to the 20k pull up resistor on the Arduino Rx pin.
The Arduino Uno R3 uses 5vdc I/O levels.
Regards,
TCIII AVD
Your right. And I accounted for that- hence low is around 300mV.
Without that 100K, low would be closer to zero (if no Arduino pullup).
Without that 100K, and with the Arduino 20K pullup, low would still be 1.7V-ish. (based on 5V Arduino)
So the 100K is not the problem. 300mV is less than the Ardunio low threshold (approx. 500mV).
It's that 20K pullup- it's going to break things in any combination- apart from some additional level shifter or buffer as you've said.
That's why I'm sure that the issue could be resolved on the Arduino side.
Just remove the internal-pullup during serial-rx.
There must be a register (or combination of registers) that need setting in serial mode, to disable that pesky pullup ? I'm ready to be amazed if there is no such possibility! Just it might need more than the single command that @robotsRcool kindly shared above. For example, sometimes these uC IOs need a global pull register setting, as well as the individual pin states.
One other thought... If the user has noise concerns, they could re-enable the Arduino internal pullup other times (when not rx-ing serial)- although I thought DHB10 was driving the output "push-pull / high-low", rather than floating high, so noise shouldn't typically be an issue. That said... If the DHB10 code is running open-drain serial, then a quick edit of the code could improve that for Arduino users, to make it always drive high when needed. I'm pretty sure that's OpenSource code, but it not I could help with finding the code and sharing an updated version as described.
@Tarkahn2019 I reproduced your problem today and got it working in my setup by moving Tx to pin 11 instead of 13 since the LED connected to that pin on my board seemed to cause some problems and then making a small tweak to the Arlo source code. SoftwareSerial::flush() is now a NOP (the Arduino changed the meaning of this function awhile ago) so I modified the code to manually read out the response to the TXPIN command so that it doesn't get confused as the response to future version requests.
void ArloRobot::begin(SoftwareSerial &serial)
{
dhb10 = &serial;
dhb10->print("txpin ch2\r"); // Receive on different pin
delay(20); // Wait for reply
// Clear input buffer
while (dhb10->available())
{
dhb10->read();
}
}
Is that "pesky" LED on the Arduino, or the shield ?
Do you happen to know the LED resistor value, and also if that's going to 5V, 3.3V or GND ?
It is on my Arduino clone, a Freeduino. I don't have a shield.
I don't have a schematic for my board but I did trace it out with my multimeter and D13 seems to be connected to a 1k resistor, which then connects to a green LED, which then connects to Gnd. I see that one Arduino Uno reference design shows the same but with a 500 ohm resistance instead.
I investigated the D13 issue a bit more tonight. The LED that is attached to the D13 pin on most of the Arduino boards acts as a pull-down on that pin. This means that the DHB-10 will see a START bit when the AVR is first reset and gets confused and misses the first TXPIN command sent to it. My workaround to this issue was to just delay for 1 millisecond before sending the TXPIN to make sure that the DHB-10 sees a STOP or idle condition on the line for a few frames first to recover from the earlier errant START pin reception. With the following change to the Arlo code, I was able to run the original test as is with no hardware modifications.
void ArloRobot::begin(SoftwareSerial &serial)
{
// Delay for a few serial frames to let the DHB-10 deal with the fact that the D13 pin
// was initially pulled low by the LED attached to this pin on most Arduino boards.
delay(1);
dhb10 = &serial;
dhb10->print("txpin ch2\r"); // Receive on different pin
// Wait for response to TXPIN command.
delay(20);
// Discard the TXPIN response so that it doesn't get confused as response for subsequent
// motor command.
while (dhb10->available())
{
dhb10->read();
}
}
I had forgotten about the Arduino Uno LED being attached to pin 13 on the Uno pwb.
I will give the code change a shot. I assume that your code is a modification of the Arlo cpp?
On the other hand I guess that the trace to the Arduino Uno LED on pin 13 could be cut to remove the LED load from that pin?
Update: I inserted your code snippet into the ArloRobot.cpp and got a good compile for my Arduino Uno R3, however it did not improve the Propeller response back to the Arduino. If you got yours to work, you must have a charmed Arduino.
I believe that the Propeller is receiving the firmware and software version requests from the Arduino because I am getting half the requested response from the Propeller with the hardware being received as "1" however the firmware always comes back as a "0" instead of "10".
Like Tarkahn2019 I get the following response with or without your ArloRobot.cpp modification:
fwver = 0
VER\r \r
hwver = 1
HWVER\r 1\r
I almost get the feeling that the Propeller is receiving commands from the Arduino at 19200 baud, but is responding at a baud rate that is not 19200. Is that possible?
Here is the response I received from Parallax Tech Support concerning the the communication issue documented in this thread:
"The AVR in the Arduino Uno does have a Schmidt trigger on the
input, which cannot be disabled, that can make it susceptible to
signal quality issues, when interfacing with 3.3 volt devices, like
the DHB-10. The AVR's pull-up resistors are optionally enabled, and
disabling them could help with signal quality.
Are you using the same example code and libraries as the
Troubleshooting Your Arlo + BOE Shield Guide? If not, which library
are you using? Also, can you give us the make and model of the
Arduino board you are using, so we can double check the input
specifications on it?
We may be able to get it working without any extra hardware,
although adding a buffer could make it work better under more
circumstances. You can draw 3.3 volts from the encoder header, with a
Y cable, if you do need it, though.
While waiting for a response from Parallax Support to my followup email, I ran some of the additional Arduino BOE/Arlo program tests like other members on this thread and here is what I found:
I ran the 3 second motor test and the DHB-10 ran the motors in the forward direction for the allotted time and then stopped.
The transmit communication between the Arduino and the DHB-10 Propeller is obviously working or the wheels would not have turned.
I then proceeded to run the encoder test and I did get counter responses for both the right and left encoders though they were not equal. The left counter was around 298 and the right counter was 315.
I believe that they should both be close to equal and less than 200? Though I am using the original Eddie Motors which may turn the wheels faster than the newer Arlo motors.
This might be due to the marginal communication from the Propeller and the Arduino receive pin 12 input causing the received readings not to be accurate?
I next tried the "Forward, Left, Right, Backward" test and the wheels responded correctly.
I was able to run the "Run Arlo with the Terminal" test and Arlo responded correctly to the "go 32 32", and "go 0 0" commands from the terminal, but did not return the pair of distance values when sent the "dist" command.
It is interesting that the Propeller responded with the encoder counts in the "Encoder Test", but did not respond at all to the "dist" command request during the "Run Arlo with the Terminal" test.
@TCIII The issues you are hitting are pretty much the same as I was hitting before I added the code to the end of ArloRobot::begin() to discard the response from the TXPIN command. Since you have applied that change and still hit these issues, I don't know what is happening. Hopefully someone else will be able to shed some light on it. It smells like a software issue to me since you appear to be getting back valid but unexpected bytes and not complete garbage.
@TCIII The issues you are hitting are pretty much the same as I was hitting before I added the code to the end of ArloRobot::begin() to discard the response from the TXPIN command. Since you have applied that change and still hit these issues, I don't know what is happening. Hopefully someone else will be able to shed some light on it. It smells like a software issue to me since you appear to be getting back valid but unexpected bytes and not complete garbage.
Thanks for the response, much appreciated.
It still is a mystery to me how you got your code snippet to work and it doesn't for me.
Yes, like you I think that it is a software issue probably hidden away in the ArloRobot.cpp. I am an intermediate C++ programmer so some of the ArloRobot.cpp code structure is somewhat of a mystery to me.
I think that I might have found a viable software solution to the DHB-10 Propeller to Arduino/BOE Shield communication issue.
I feel that this solution is only a temporary fix as Parallax Support needs to determine why the DHB-10 Propeller spin code is not communicating correctly with the Arduino/BOE Shield.
Also, this issue does not appear to be a hardware issue as was originally assumed at the start of this thread.
I ran the "Control BOE Shield Arlo with the Terminal" program this morning and initially got the usual zero response for the dist command after running rst, go 32 32, and then go 0 0.
However after running the same terminal commands again, I waited a few seconds and then sent dist again and actually received a response consisting of a pair of numbers that seemed reasonable.
So it is beginning to look more and more like a communication issue on the DHB-10 Propeller Ch 2 side of the Arduino/BOE serial Rx line pin 12.
I did further testing with the "Test Arduino to DBH-10 Communication" program and found that if I modified the original Arduino code to request the firmware version like this: fwver = Arlo.readFirmwareVer();, delay(10), fwver = Arlo.readFirmwareVer(); I received the correct response of fwver 10 to each query. I did the same for the hardware version and got the correct hwver 1 response to each query.
I experimented with the delay value and found that 10ms is as short as the delay value can be and still have reliable communication.
Maybe a review of the DHB-10 Propeller serial communication initialization and send/receive code is in order here to determine why the Propeller has to receive either a measurement or an information command two times in a row to respond correctly to the initial command request?
@TCIII Hi TCIII- could you keep the replies on one thread please? Otherwise the topic will get diluted fast
I've trimmed the other two threads for you.
Ok, will do. However it is interesting that I found two other threads with the same Arduino/BOE Shield to DHC-10 communication issue. Doesn't anyone do a search of the Robotics sub-forum before posting a new thread?
Here is a response from Parallax Support concerning my suggestion to request a measurement or information command twice with at least a 10ms delay between each command in order to receive a valid response from the DHB-10 Propeller:
"The program may be trying to read the response, before it arrives.
By default, all responses end in a carriage return. If the buffer is
large enough to hold an entire response (32 bytes should be enough),
after transmitting I would recommend repeatedly reading the most
recently received byte, without flushing it from the buffer, then
parsing and flushing the entire buffer, when the most recent byte
contains a carriage return. This is how the DHB-10 processes incoming
data. Another option is to pause between transmitting and parsing the
response, as you did in your test. It will take a little longer to
run, but it is easier to implement.
― David Carrier
Parallax Inc."
Is there anyone on this thread with good C++ programming experience who can review the ArloRobot.cpp code in order to improve the Arduino response to information or measurement commands without having to resort to sending each command twice with a 10ms delay between commands?
Comments
The bit I still don't understand is the impact of the Arduino pullup being disabled !
Sure- with that enabled, the low is probably about 1.8V (due to the voltage divider effect of that ~20K pullup). Sure, that's not low enough to be read as low.
However, with the Arduino internal pullup disabled, there should be no reason for the low voltage to be above ~300mV, and that would certainly read as low.
I'm wondering if the Arduino needs some extra code to "really" disable that internal pullup. Maybe something else needs writing to the pin register, or some global control.
Has anyone with this issue actually checked that the Arduino is definitely NOT pulling up the input for the duration that it's expecting some serial input ?
Another question for clarity-- is the Arduino in use 5V or 3.3V IO level ?
Don't forget that the Propeller Tx pin is also having to pull down 3.3v to 0v through a 100k resistor on the DHB-10 board which is not much compared to the 20k pull up resistor on the Arduino Rx pin.
The Arduino Uno R3 uses 5vdc I/O levels.
Regards,
TCIII AVD
Your right. And I accounted for that- hence low is around 300mV.
Without that 100K, low would be closer to zero (if no Arduino pullup).
Without that 100K, and with the Arduino 20K pullup, low would still be 1.7V-ish. (based on 5V Arduino)
So the 100K is not the problem. 300mV is less than the Ardunio low threshold (approx. 500mV).
It's that 20K pullup- it's going to break things in any combination- apart from some additional level shifter or buffer as you've said.
That's why I'm sure that the issue could be resolved on the Arduino side.
Just remove the internal-pullup during serial-rx.
There must be a register (or combination of registers) that need setting in serial mode, to disable that pesky pullup ? I'm ready to be amazed if there is no such possibility! Just it might need more than the single command that @robotsRcool kindly shared above. For example, sometimes these uC IOs need a global pull register setting, as well as the individual pin states.
One other thought... If the user has noise concerns, they could re-enable the Arduino internal pullup other times (when not rx-ing serial)- although I thought DHB10 was driving the output "push-pull / high-low", rather than floating high, so noise shouldn't typically be an issue. That said... If the DHB10 code is running open-drain serial, then a quick edit of the code could improve that for Arduino users, to make it always drive high when needed. I'm pretty sure that's OpenSource code, but it not I could help with finding the code and sharing an updated version as described.
void ArloRobot::begin(SoftwareSerial &serial) { dhb10 = &serial; dhb10->print("txpin ch2\r"); // Receive on different pin delay(20); // Wait for reply // Clear input buffer while (dhb10->available()) { dhb10->read(); } }Is that "pesky" LED on the Arduino, or the shield ?
Do you happen to know the LED resistor value, and also if that's going to 5V, 3.3V or GND ?
It is on my Arduino clone, a Freeduino. I don't have a shield.
I don't have a schematic for my board but I did trace it out with my multimeter and D13 seems to be connected to a 1k resistor, which then connects to a green LED, which then connects to Gnd. I see that one Arduino Uno reference design shows the same but with a 500 ohm resistance instead.
Looking at the Arduino BOE Shield schematic, there is no LED on either pins 10 (X5-3),11(X5-4),12 (X4-3), or 13(X4-4).
The LED (L2) that comes on when switch SWI is set to position 2 is tied to V_Servo which should be set to 5vdc.
Also, moving Tx to pin 11 will mess up the PING connections.
Regards,
TCIII AVD
I investigated the D13 issue a bit more tonight. The LED that is attached to the D13 pin on most of the Arduino boards acts as a pull-down on that pin. This means that the DHB-10 will see a START bit when the AVR is first reset and gets confused and misses the first TXPIN command sent to it. My workaround to this issue was to just delay for 1 millisecond before sending the TXPIN to make sure that the DHB-10 sees a STOP or idle condition on the line for a few frames first to recover from the earlier errant START pin reception. With the following change to the Arlo code, I was able to run the original test as is with no hardware modifications.
void ArloRobot::begin(SoftwareSerial &serial) { // Delay for a few serial frames to let the DHB-10 deal with the fact that the D13 pin // was initially pulled low by the LED attached to this pin on most Arduino boards. delay(1); dhb10 = &serial; dhb10->print("txpin ch2\r"); // Receive on different pin // Wait for response to TXPIN command. delay(20); // Discard the TXPIN response so that it doesn't get confused as response for subsequent // motor command. while (dhb10->available()) { dhb10->read(); } }I hope the same works for you!
I had forgotten about the Arduino Uno LED being attached to pin 13 on the Uno pwb.
I will give the code change a shot. I assume that your code is a modification of the Arlo cpp?
On the other hand I guess that the trace to the Arduino Uno LED on pin 13 could be cut to remove the LED load from that pin?
Update: I inserted your code snippet into the ArloRobot.cpp and got a good compile for my Arduino Uno R3, however it did not improve the Propeller response back to the Arduino. If you got yours to work, you must have a charmed Arduino.
I believe that the Propeller is receiving the firmware and software version requests from the Arduino because I am getting half the requested response from the Propeller with the hardware being received as "1" however the firmware always comes back as a "0" instead of "10".
Like Tarkahn2019 I get the following response with or without your ArloRobot.cpp modification:
fwver = 0
VER\r \r
hwver = 1
HWVER\r 1\r
I almost get the feeling that the Propeller is receiving commands from the Arduino at 19200 baud, but is responding at a baud rate that is not 19200. Is that possible?
Regards,
TCIII AVD
Here is the response I received from Parallax Tech Support concerning the the communication issue documented in this thread:
"The AVR in the Arduino Uno does have a Schmidt trigger on the
input, which cannot be disabled, that can make it susceptible to
signal quality issues, when interfacing with 3.3 volt devices, like
the DHB-10. The AVR's pull-up resistors are optionally enabled, and
disabling them could help with signal quality.
Are you using the same example code and libraries as the
Troubleshooting Your Arlo + BOE Shield Guide? If not, which library
are you using? Also, can you give us the make and model of the
Arduino board you are using, so we can double check the input
specifications on it?
We may be able to get it working without any extra hardware,
although adding a buffer could make it work better under more
circumstances. You can draw 3.3 volts from the encoder header, with a
Y cable, if you do need it, though.
Thank you,
David Carrier
Parallax Inc."
Regards,
TCIII AVD
While waiting for a response from Parallax Support to my followup email, I ran some of the additional Arduino BOE/Arlo program tests like other members on this thread and here is what I found:
I ran the 3 second motor test and the DHB-10 ran the motors in the forward direction for the allotted time and then stopped.
The transmit communication between the Arduino and the DHB-10 Propeller is obviously working or the wheels would not have turned.
I then proceeded to run the encoder test and I did get counter responses for both the right and left encoders though they were not equal. The left counter was around 298 and the right counter was 315.
I believe that they should both be close to equal and less than 200? Though I am using the original Eddie Motors which may turn the wheels faster than the newer Arlo motors.
This might be due to the marginal communication from the Propeller and the Arduino receive pin 12 input causing the received readings not to be accurate?
I next tried the "Forward, Left, Right, Backward" test and the wheels responded correctly.
I was able to run the "Run Arlo with the Terminal" test and Arlo responded correctly to the "go 32 32", and "go 0 0" commands from the terminal, but did not return the pair of distance values when sent the "dist" command.
It is interesting that the Propeller responded with the encoder counts in the "Encoder Test", but did not respond at all to the "dist" command request during the "Run Arlo with the Terminal" test.
Comments?
Regards,
TCIII AVD
Thanks for the response, much appreciated.
It still is a mystery to me how you got your code snippet to work and it doesn't for me.
Yes, like you I think that it is a software issue probably hidden away in the ArloRobot.cpp. I am an intermediate C++ programmer so some of the ArloRobot.cpp code structure is somewhat of a mystery to me.
Regards,
TCIII
I think that I might have found a viable software solution to the DHB-10 Propeller to Arduino/BOE Shield communication issue.
I feel that this solution is only a temporary fix as Parallax Support needs to determine why the DHB-10 Propeller spin code is not communicating correctly with the Arduino/BOE Shield.
Also, this issue does not appear to be a hardware issue as was originally assumed at the start of this thread.
I ran the "Control BOE Shield Arlo with the Terminal" program this morning and initially got the usual zero response for the dist command after running rst, go 32 32, and then go 0 0.
However after running the same terminal commands again, I waited a few seconds and then sent dist again and actually received a response consisting of a pair of numbers that seemed reasonable.
So it is beginning to look more and more like a communication issue on the DHB-10 Propeller Ch 2 side of the Arduino/BOE serial Rx line pin 12.
I did further testing with the "Test Arduino to DBH-10 Communication" program and found that if I modified the original Arduino code to request the firmware version like this: fwver = Arlo.readFirmwareVer();, delay(10), fwver = Arlo.readFirmwareVer(); I received the correct response of fwver 10 to each query. I did the same for the hardware version and got the correct hwver 1 response to each query.
I experimented with the delay value and found that 10ms is as short as the delay value can be and still have reliable communication.
Maybe a review of the DHB-10 Propeller serial communication initialization and send/receive code is in order here to determine why the Propeller has to receive either a measurement or an information command two times in a row to respond correctly to the initial command request?
Comments?
Regards,
TCIII AVD
I've trimmed the other two threads for you.
Ok, will do. However it is interesting that I found two other threads with the same Arduino/BOE Shield to DHC-10 communication issue. Doesn't anyone do a search of the Robotics sub-forum before posting a new thread?
Regards,
TCIII AVD
Here is a response from Parallax Support concerning my suggestion to request a measurement or information command twice with at least a 10ms delay between each command in order to receive a valid response from the DHB-10 Propeller:
"The program may be trying to read the response, before it arrives.
By default, all responses end in a carriage return. If the buffer is
large enough to hold an entire response (32 bytes should be enough),
after transmitting I would recommend repeatedly reading the most
recently received byte, without flushing it from the buffer, then
parsing and flushing the entire buffer, when the most recent byte
contains a carriage return. This is how the DHB-10 processes incoming
data. Another option is to pause between transmitting and parsing the
response, as you did in your test. It will take a little longer to
run, but it is easier to implement.
― David Carrier
Parallax Inc."
Is there anyone on this thread with good C++ programming experience who can review the ArloRobot.cpp code in order to improve the Arduino response to information or measurement commands without having to resort to sending each command twice with a 10ms delay between commands?
Regards,
TCIII AVD