Raspberry pi and DHB10
Juliussssss
Posts: 12
Hi,
I'm not super great with electronics and dont understand why raspberry pi can send serial commands to DHB-10 contorl board but not receive any. I understand it has something todo with the wiring on DHB side?
So I believe DHB uses 5V for serial communication, whilst raspbeery uses 3.3v. But I tried using a pull down from DHB and it didnt work. I can successfully send commands to DHB, but not receive any (receiving on arduino works)
Does someone know how to solve this?
Thanks
I'm not super great with electronics and dont understand why raspberry pi can send serial commands to DHB-10 contorl board but not receive any. I understand it has something todo with the wiring on DHB side?
So I believe DHB uses 5V for serial communication, whilst raspbeery uses 3.3v. But I tried using a pull down from DHB and it didnt work. I can successfully send commands to DHB, but not receive any (receiving on arduino works)
Does someone know how to solve this?
Thanks
Comments
Cannot help you with the Pi part, but I can confirm this about the DHB-10 serial port:
DHB-10 can receive at 3.3V or 5V
DHB-10 will transmit at 3.3V
Technically, the DHB-10 has a 100K pull-up to 3.3V on each of it's four control headers (serial 1&2, aux 1&2).
There is also a series 10K resistor on each I/O to limit current so that you can safely input 3.3V or 5V
One thought- the DHB-10 serial will idle high (because of the pull-up). Adding the external pull-down won't help you, but adding an extra pull-up externally might, if you wish to run very fast serial. (So remove the pull-down, and also make sure Pi doesn't have any internal pull-downs configured on it's IO pins)
Also check the type of serial you are using- make sure your serial init/config settings in Pi are for an idle-high scheme (not idle-low).
Hope you find a solution soon.
Please keep us posted, and ask for more help if your still stuck!
You may need a Level Shifter to bridge between the DHB-10 and the Raspberry Pi which might be a good idea anyway to protect the Pi.
Curiosity found me this document:
http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications
Seems Pi has a 50K pull resistor, which you should disable on the I/O going to the DHB-10. (Is that possible?)
No need to level shift because both devices operate at 3.3V, but that 50K pull resistor inside Pi (also any external pull resistor you might have added) will impact the minimum and maximum voltage levels in such a way that Pi won't be able to determine if the signal is high or low reliably (and hence you can't get the serial replies). So removing your external pull-down and disabling the Pi internal pull-down should solve.
Dont really see the relavance, but im powering DHB and pi from a 12V PC power supply. (SOme hugeass capacitors added for reliability) ofc there is a DCDC converter for pi.
Thanks. I am not adding anything to the serial connections. so pi txrx pins go straight to DHB ones. Ill try to debug using your suggestions.
What do you mean here? I'm trying to find this in pySerial documentation. Or is this some config on pi itself. Could you link to something about this?
Anyway... I suspect the internal Pi io resistor is the real issue. I'd focus on that first.
- I'm stupid (and also wtf is this) DHB10 by default uses single pin for serial (omg wtf bbq) so sending a TXPIN CH2 before attempting to read, seems to have fixed the coms issue.
Still pending the issue why DHB stops working and starts flashing its LEDs.
I can try to explain about the serial thing you mentioned...
The bi-directional single pin serial provides compatibility with many other Parallax products, including the Activity Board which is included with the Arlo robot (and for which the DHB10 was originally created). You will see the 3-pin headers top-right on the Activity board, so it's really easy to connect things together.
Parallax has long used this 3-way cable standard for interfacing, often referred to as "servo" headers or "servo" cable. They are typically marked B R W (Black Red White) after the cable colors which are used, and these electrically represent GND Vdd Signal.
It has been a very simple and successful standard AFAIK- especially in Education. Parallax carries a range of cable sizes, and bulk kit options- here's one example: https://www.parallax.com/product/800-00060
With regard the DHB10, like many other Parallax sensors & boards, it can be controlled via PWM or Serial commands, all over the same single bi-directional 3-way cable.
I'd be surprised if you can't interface to other uC's (such as your Pi) using single pin serial- you should give it a go! Handy way to save an I/O pin too!
ref. the LED flashing... is there anything in the user-guide which could help you decode what the LED message means? Maybe those fault LEDs flash at different rates or patterns to indicate what the issue is?
I read the firmware and now can see whats causing the board to stop driving. These are edu boards, not very versatile. I'm using them essentially for industrial applications. Rough terrain, multiple sources of disturbance. And the firmware shuts off the board if the wheels havent moved for half a second (or at least that what it says. not very consistent with practice, but seems like thats the culprit for sporadic shutdowns). For the same price as motor kits and the board I probs could have gotten some decent maxon motors and drivers.
The user guide says nothing about led flash patterns. but since firmware is opensource you can read where thats triggered. I plan to remove all triggers like this:
if StillCnt[Side] => DIVISOR ' If the offset was high and the motor hasn't moved for the last second
Motors.Stop ' Then something is wrong; force off all motor power
PDRunning := -1 ' Let parser know motor power is disabled
Blink(24, |< L_FAULT_LED | |< R_FAULT_LED) ' Stop servicing the motors
And reflash firmware. hopefully increasing robustness as I expect my motors to be often stalled or tucked in other directions etc etc.
The hardware features a really robust motor driver IC, so the software-safety shouldn't be needed for most uses. Definitely looks like that firmware was written with EDU in mind, sure. Ha... There's probably a bunch of teachers would like the robot to stop when something is wrong, rather than racing across the room and hitting something
You know, all this considered, I have to disagree with your comment about versatile. I think you've demonstrated to yourself that this controller is VERY versatile. All hardware and code is opensource, so you can fine tune and modify the behavior so it's exactly matching your needs.
The drive fets are also super chunky- 40 or 50A as I recall. The fuse and P-Fet at VIN limit the total maximum current draw. Some time ago we had it running some loads that were twice those rated (larger fuse installed of course). The thing got insanely hot after a while, but adding a fan solved that, and everything ran happily ever after. Of course this is not an official recommendation, but the point is that with the benefit of access to the opensource schematic, you have the opportunity to make your own educated choices for industrial use, rather than sticking with a single use case that the firmware and docs/specs were created for. Yep- Versatile!
Would be interesting to see what you've created, if your able to share some pics!
re checks: Not too sure whats the point of those. The issue is that they stop the board from working and require manual reset. Thats not an option.
versitality: yes and no i guess. You're right, since its programable its versatile. Just that its not versatile by default.
Product: I need to move away from this kit anyway, and get myself some hall sensored motors. I'm having dust issues with visual encoders here.
pics: sure, once its published, ill link it here.