I’m loving the UM7 for my application, which logs orientation, GPS coordinates, and UTC time when cameras fire during aerial photography flights.
I see in the literature that UTC time is captured when a GPS is “properly” connected and I infer from the literature that it is substituted for UM7 time if PPS is connected to TX2. I have done this and GPS data is being output in the appropriate NMEA messages. However, “time” is still UM7 time, not UTC or GPS time.
Has anyone succeeded in getting GPS time into the NMEA messages?
Also, I’ve scoured the internet for information about using the UM7 and can’t find anything, except on this and the manufacturer’s forums. Is anyone actually using the UM7 with a GPS?
Did you also set PPS bit 8 of the CREG_MISC_SETTINGS register?
From the UM7 data sheet: If set, this bit causes the TX2 pin on the IO Expansion header to be used as the PPS input from an external GPS module. PPS pulses will then be used to synchronize the system clock to UTC time of day.
This may only mean that the seconds change synchronously with the change in UTC seconds.
But you do have the GPS time. Among several other possibilities, you can read out the DREG _GPS_TIME register from the UM7. It contains the GPS-reported UTC time of day in seconds.
The beauty of the device, for me, was that I could set it up using their interface software and have it send a NMEA style message that I would simply parse. And, it works great, except for the GPS time, which apparently isn’t available in any of the NMEA messages.
It just doesn’t seem sensible to me not to include GPS time in the GPS message.
I’m sure I’m not the only one that would appreciate not having to do extensive programming to get that one piece of missing data.
Meanwhile, I’ve written a sketch to read the binary GPS packet. It successfully gets the packet and parses it, but the data isn’t even close. Either I’m misinterpreting the data structure in the UM7 datasheet, or it’s wrong.
Three messages to Redshift, via both email and their web site, go unanswered.
Success! The problem was that my code failed at converting the 4-byte messages to floating point. By reversing the process (converting my latitude to 4-bytes) I could see I was getting the right 4 bytes from the UM7 packets and shifting them into a 32-bit variable correctly. Then, it was just a matter of finding the correct way to convert a long to a float.
Still no response from Redshift, which is disappointing. I hope this doesn’t portend that the UM7 has reached the end of its life cycle, now that I’ve figured it out!
After spending an inordinate amount of time getting UTC out of it programmatically, I gave up on the UM7 as an AHRS for a flight data logger. The Euler roll, pitch, and yaw angles would not settle down, no matter how carefully I calibrated it. Maybe I’m inept. Maybe I got a bad unit. I don’t know, but I didn’t want to invest any more time to it. Instead, I dug up some old ArduIMU boards and Ardupilot code, attached the GPS, and customized the code to output what I needed. Roll, pitch, and yaw are steady as a rock.
