Hi there. When it will be possible to test it? Thanks?
Sorry, I have postponed the coding because I have to do other thing first and I got the impression that the interest was declining. I hope to finish the first beta version of the programm next week.
Iām now almost ready. Only parts of the the antenna offset calculations are missing. I hope to finalize the beta tomorrow evening and need someone who is ready to test the programm against his/her own calculations. @wsurvey, are you still ready to do that?
I would like to give it a shot if possible
Hello Tobias. Yes, I can test.
Great! I will send an link tomorrow.
Hello. I would like to test it too If possible. Many thanks.
Hi Tobias! I also developed a Matlab script based processing toolchain, I would be happy to compare against it. We are flying with a dual antenna setup - 2 reach 30 cm from each other gives pretty good heading estimate, and the timemarks are the same +/- 5e-8 sec.
Btw.: The .ubx file contains both the rising and falling edge detection time.
Hi Balint,
great, thank you for the hints, two units are an interestimg and straight forward idea, unfortunately Iām running out of units ;-).
What about the magnetometer, I guess someone more familiar with programming should easily combine the gps and magnometer data into very precise heading data? I hope @emlid will do that soonā¦ .
Can you give more information about the rising and falling edge topic? How do you integrate that into your script, are you using the mean of the two values? I have to look tomorrow what is the time difference between the two.
Are you controlling RTKlib from your script to? I hope to implement that later onā¦ .
Hello Balint,
How might one go about extracting both leading and falling edge events from the UBX?
Hi! I extract both, but use only the falling edge: that is the time when exposure starts, I simply add (exposure time / 2) to it and evaluate the position there.
I am controlling ubx conversion and rtk post processing from script, even sp3 and clk IGS product download.
Thanks Balint. Is there any tools available for extracting both falling and rising edges?
Iāve looked into CONVBIN but that doesnāt seem to do it. The emlid version of RTKCONV seems to only output the falling edge event. How does the layman get at this information?
Hi Balint,
interesting, I guess you will not disclose parts of your code? Of course I would be very interested to improve my codeā¦ .
I think an ideal script should:
- download the UBX-files from the Reach-Modules via ftp
- load the coresponding LOG-files from the drone (my case from Arducopter)
- list the surveys
- provide the possibility to process them
- as image timemarks with time and antenna offsets (-> vehicle heading which is merged from gps, magnetometer and imu.)
- as GCPs - load the necessary IGS products
I guess someone with programming experience could realize that in less than two days, so I still wonder why @emlid does not provide that.
Is the āexposure compensationā necessary? Does it add to the precision of the position? If I fly 8 m/s and the camera exposure is 1 ms, than the vehicle moves 0.8 cm during this time?! If the vehicles altitude is 90m the resolution is significant lower than the movement of the vehicle. So its only relevant for a plane and a >50 MP camera?
Do you use Matlab? I can share the .m files of the code for timemarks, in case you find it useful, but I doubt having the rising edges would help you!
No unfortunately I donāt use/have matlab. Thanks for the offer though.
The rising edges might help me as Iām detecting the LED blinks of my phantom 4, not camera trigger. The LED coming back on is what Iām detecting. This occurs about 200ms after the exposure. If the LED going off is 200ms before, then my exposure would be in the middle of the two events, or a simple weighted average of the two.
Just out of interest, if I linked you to a UBX file, as a once-off could you send me back the extracted rising and falling timestamps? I am curious about the timing and the consistency of the photoresistor response in my setup.
Do you know if U-blox provide free developer tools, or similar, for getting at all the good stuff within the UBX?
The code is ready, but Iām still searching for an error, so there is another delay.
@wsurvey I have tried to read the UBX file with python, it does work but I would need to figure out how to process the information. I guess one would have to find the UBX-TIM-TM2 messages in the binary code. Than one should implement a function which handels the Phantom behavior. Unfortunately I do not have a Phantom, but I have some Canon compact cameras which show even stranger led behavior, so I might consider to integrate such a function later on.
@wsurvey What Iām wondering is whether you get more timemarks than pictures because the timemark pin is held high or low over more than one epoche or because the signal from the LED is ānoisyā. What sensor are you using at the LED? I used a 0.1 ā¬ photo resistor which has some ānoiseā and did create double timemarks.
@vbnhu how do you do that in Matlab?
I would also be interested in how to download the IGS products, I guess I can figure that out by myself, but I would be very happy if you could help with some small code examples.
hey Tobias,
my time marks are clean. I get one time mark for every time the pin is driven low. I use a large photoresistor (cost 3.25 australian micro-pesos) , which drives the pin low when the LED comes back on after a photo. The photoresistor is either slow enough, or the LED pulsed fast enough that I donāt get enough noise to change the pin state. This seems to be at about 7kohm which corresponds to approx 1.7v on the pin.
I took great care to absolutely black out the LED housing so that the resistor would swing quickly from very high resistance to very low; it shouldnāt ever be dwelling near a middling resistance which could cause faulty time marks. It goes quickly from over 500kohm to about 70ohm (from memory). Triggering is at about 7kohm.
My only āproblemā is missing time marks. I donāt know if itās my resistor, DJI faulty LED driving, or emlid/u-blox event recording. But I sometimes get one or two missing timestamps per 200-300 photo flight. That is not a big problem for me.
so I ask you the same type of question: Is there any documentation from u-blox to assist? or do you just covert it all, however you can, and essentially search through the mess?
I assume emlid know how to extract. Iām mildly surprised they donāt offer the option to output rising or falling edge time marks to, or both in the emlid version of RTKCONV.
uBlox documentation
Message description: page 85
Only the last rising and falling edge detected between two epochs is reported since the output rate of the UBX-TIM-TM2 message corresponds to the measurement rate configured with UBX-CFG-RATE (see Figure below).
As far as I understand it, from the graph and the text, there should be always a leading falling edge and then the following rising edge. It is not described what happens if the rising edge is in the following epoche. This is very likely if you have pulses which are almost as long as the epoche 200 ms = 5 Hz. I could imagine that that is the reason for lost time marks.
The code should include a detection for lost timemarks, i.e. if there is a longer interval than x seconds between the timemarks? One could even interpolate the position of this timemark.
Emlid is not interested in the topicā¦ . One must admit that we are less than a handful of people interested in the subjectā¦ .
Binary protocol description: page 379
Feel free to post a python code to read the TIM-TM2 messages out of the binary dataā¦ . I will be happy to integrate that. It seems fairly easy, I will do it some day: example. But if someone writes the code I will integrate it at the weekend. I need a panda dataframe with a timedata object and the information whether it is a falling or rising edge. Or better one row with both information.
perhaps. Could be hard to distinguish between failed event detection in a run of timed photos, and an actual missed photo. both occur unfortunately. Also if using 3rd part software for mission planning then there will be unusual time gaps near turns and the like.