Good day again
For my previous project I also have a CHR-6dm Attitude and Heading Reference System, I have two separate projects that are similarly linked. More or less comparing the two systems for accuracy/reliability for a university project.
I tried wiring my CHR-6dm Attitude and Heading Reference System directly to Logomatic V2 SD Datalogger but all I get is wierd wonky data. Ive changed the baud rate setting in the logomatic to match what the factory default for the AHRS but still no good data. Im wired to TX/RX on the AHRS and TX/RX on the UART for the Logomatic.
Any help would be GREAT!
thanks in advance
Do the two devices have a common ground?
Do you have a USB-to-serial adapter? If so, you should be able figure out which device is having the problem by first using it to stream data from the sensor directly to your computer and then using it to send data to the data logger.
I’m also having the same problem reading data from CHR6DM. I have a USB/serial adapter that is set to 115200, 8 bit, parity none, stop 1 bit, flow control none. When I connect Tx on CHR6DM to Rx on my serial adapter, I only see garbage characters. Do I need a TTL-to-RS232 adapter to see data correctly? I don’t have one available so I want to check if one is needed.
Also, I would need to modify the existing firmware on CHR6DM to control two servos via your Micro Serial Servo Controller. Where do I find instructions on how to reflash CHR6DM with my firmware? Where do I find the free development tools that was mentioned in pololu.com/catalog/product/1253?
Do you have the grounds connected between the CHR6DM and your serial adapter? Can you please explain how you are wiring everything?
I’ve been using a usb/serial adapter from Trendnet. Here is their adapter description: trendnet.com/products/proddetail … -S9&cat=49
Initially, I had just wired the TX from CHR6DM to the RX on my usb/serial adapter and received garbage characters. After reading your post, I also connected GND (next to VIN+) of CHR6DM to the ground pin (pin 5) of my usb/serial adapter and am still receiving garbage characters. I’m suspecting it’s the TTL/RS232 conversion problem. I wasn’t aware of Pololu USB-to-serial adapter until just now.
Hello. You should start with the existing CHR6DM firmware and make modifications to it until it does what you want. You can get the firmware directly from the manufacturer by visiting CHRobotics.com or you can get it from our resources page:
Unfortunately, that download doesn’t come with any kind of README file, but I noticed a “.rapp” and “.rprj” file in there which means that you are probably supposed to compile it using the Ride7 IDE by Raisonance.
I don’t like using Ride7 for STM32 development; instead I use Yagarto + Eclipse, but it will be much easier for you to get started if you use Ride7. Yagarto and Ride7 basically use the same compiler so it is relatively easy to switch later if you want to.
You will probably need the datasheet of the STM32 processor on that board. That datasheet is available in the product’s resources tab on our website.
ST provides libraries for using the USART and all the other peripherals on the board; I think they are included as part of Ride7 but I’m not sure.
Thanks David and Ryan for your input.
I just have a few more questions on the products:
Since CHR-6d IMU Development Kit does not work with CHR-6dm, do you have one that works with it? I would assume I would need one to flash my modified firmware onto CHR-6dm.
What do you recommand as the component to control the Micro Serial Servo Controller from CHR-6dm’s TX pin?
I think your suspicions are most likely correct. That serial converter you are using is USB to RS-232, which is specified to have voltages up to between -12 and 12 V. It’s pretty unlikely that it can distinguish a 3.3V TTL-level signal, and if you were to connect the serial converter’s TX pin to the CHR-6DM’s RX pin you would likely break it. As you mentioned, We recommend the Pololu USB-to-serial adapter, which operates at 3.3V.
Here are the answers to your other questions:
I have not heard of a development kit for the CHR-6dm. Unfortunately, we do not know much more about custom firmware development for CH Robotics products, but CH Robotics has an entire forum dedicated to this pursuit. I suggest you look there for additional advice.
You would need a level converter that converts from 3.3V up to 5V. Something like this level converter from Sparkfun might work.
Even if everything is working right on the 6dm, the 6d, or the UM6, you should expect to see “garbage” when dumping the raw data to a terminal or logging it to a file. The data coming from CH Robotics’ sensors is binary data and isn’t accurately represented using ASCII characters. You should look at the datasheets for details about how to interpret the data coming from the sensors.
Yes I’m aware that the data coming in is in hex format. I did not see any ‘snp’ (ascii equivalent of hex) characters in the data I collected so I assumed they are garbage characters. I will try again after I have the right USB/serial converter. Thanks.
I use “Ord(inBuffer[i])” command as integer value received from the UM6 on Delphi.
I still had no idea, I have fail connecting my first CHR6DM last time, so I just forget it now… because I have new CHR-UM6.
Now, I am facing new problem after having CHR-UM6 connected. I just can’t understand the data from the sensor.
I have received the “snp” a.k.a “115,110,112” in integer and 12 values after the “snp” with factory default setting.
All I want is roll & pitch value only, which I expect located in 10 & 11, on the manual “page 16” the values I wanted suppose to be “estimated angles” right?
After some trial with my Delphi script (a simple one), I always receive unstable value even when the sensor remains steady and far-far away from magnetic field.
Does anyone would help, I promise to share my project after become reality.
I bought of these UM6 last week and it has been a source of great frustration. It appears to be a useful product but communications is very difficult. There is no support other than asking you to read the manual. I found some example Arduino code after scouring the web and finally managed to get the broadcast mode to work. But the output data makes little sense and the manual is hopeless. Why not put in a few examples ? I could never get the polled mode to work and after several hours and useless emails back and forth to CH robotics I just gave up on the UM6 and tossed in into the scrap bin. If anybody is using this thing tell us on the forum so others do not waste their money.
I agree, some examples would be useful. Perhaps the best example of how to read and interpret packets from the UM6 can be found in the firmware itself - specifically, the USART code: http://um6firmware.svn.sourceforge.net/viewvc/um6firmware/trunk/UM6%20Firmware/UM6_usart.c?revision=29&view=markup
This is the most recent incarnation and includes code both for parsing the serial packets and for parsing GPS packets. I’ll make some examples of basic serial communication that are a little more straightforward and post them on the CH Robotics website.
It is worth pointing out that the UM6 and the UM6-LT are fairly complex - the protocol used for communication is designed to provide the data reliably and with minimal overhead. Hence the checksum information and the inclusion of “batch” transmissions. This is highly important if the data will be used for control (i.e. on aircraft), because high-bandwidth orientation data may be necessary for control, and because erroneous data could have serious consequences (a crashed helicopter, for example).
The unfortunate side-effect is that it can take a little extra work to write the code that reads from and writes to the sensor. It is important (for starters) that the datasheet be read carefully and completely before making assumptions about how to communicate. This is true of any complex device. Read the datasheet! The exact format of the output data is described in careful detail.
It is also worth noting that when working with microcontrollers and electronics, the number of areas in which problems can manifest themselves is significant: bad, incorrect, or missing electrical connections, mismatched TTL voltage levels (3.3V vs. 5.0V), “unshared” grounds, microcontroller misconfiguration, baud rate misconfiguration, erroneous packet parsing code, ESD-damaged components, and so on, could ALL independently cause communication with the UM6 (or any other device, for that matter) to fail. It is therefore expected that users have a certain baseline of electronics experience to effectively integrate the UM6 into a custom system.
I am happy to help in whatever ways I can - if anyone has specific questions, please email me directly at email@example.com.