Lol , I just finished a blog … using 2 uarts … Please read and comment:
1 Like
@olliw42 what about adding the rm3100 mag support to the node? I use that one and it’s pretty amazing! That would be incredible to have.
Love this! Finally it’s getting some serious traction. You’re a genius and kind for contributing all this!
It is really odd because I commented on your blog and it is not in my list of topics I have replied to either.
Yes, Randy made a correction and seems that when I approved , it has been trashed… they are working on it.
It’s back (at least for me) - someone else might check though.
1 Like
Link works for me now too.
@olliw42 about the serial tunneling, as I wrote in my blog, I had issues with the Benewake sending hex code but all OK when using the ascii mode i.e. clear text values terminated with cr/lf.
As I am planning to use the Cheerson Optical Flw, this sensors sends hex code only, I suspect I will experience the same issue. Is this something we could try to fix ?
yes, we can try that
it however certainly has nothing to do with ascii or binary, the code is agnostic to this, and in fact for the gps it switches to ubx and is then binary, so you have seen it already yourself
I rather suspect the timing of how the data is packed into CAN frames. You can have a look at the BetaCopter code, the counterpart works essentially identically
one probably has to carefully look at how the data is streamed, my first guess is that in binary mode it expects a faster response to its packets, or that the library has a stricter timeouting, or that the tf stream is “interrupted” at an unfortunate point which the tf doesn’t like, or such
that’s the general disadvantage of the approach, it is probably not possible to devise on scheme which is kind of “guaranteed” to work for all
when you look at the stream with UAVCAN GUI one probably can see quickly where things go wrong
you, thus, should definitely try the other device. it has nothing to do with ascii vs binary
1 Like
@olliw42 how does this work for adding a new sensor, for example, the sdp33 airspeed sensor? Do you (personally) have to manually add the driver to the firmware and then compile the hex?
If so, too bad there isn’t a way to use something with external storage and sideload the needed driver in the correct format.
this would be so
but if you think about it that’s how CAN is desgined
@ppoirier
I took a look at the tfmini protocol, to see why there might have been issues. I’m going to refer to the standard data format in the following (i.e. what I believe is what you called hex or binary). It is actually really a very short data frame, so this shouldn’t give any problems. However, there might be an issue with a 100 Hz update rate (a rate significantly faster than what I’ve anticipated then I did the tunnel 
): The code uses a timeout of 10 ms to decide if some incoming data should be send out, so it could collide in unfortunate ways with the 100 Hz update rate. Two possible solutions:
I don’t yet fully understand the TFMini settings, but it seems to me it’s possible to achieve a data rate lower than 100 Hz. If so, I think this would be a quick first test, to see if the instabilities go away with lower rate.
Second, one could change the code to use e.g. a timeout of 8 ms, or 5 ms, or to actually make it a parameter (this timeout acts as a kind of delay to data streams which have such short data telegrams). If that should be still relevant to you, I’m happy to do the code changes.
What remains a bit unclear to me is why this would happen for the standard but not the clear text Pixhawk format, but such tests probably would show.
(btw, I’ve ordered me a TFmini, I realized that a down-facing distance sensor would be a cool addition to my copter 
)
Yes , I will test with slower data output period , as is defined in Benewake guide : https://www.robotstore.it/rsdocs/documents/sensore_distanza_TFmini-Lidar_manuale.pdf
@olliw42 OK I reduced the frame rate to 50 Hz , this is how:
Enter configuration mode by the command:
42 57 02 00 00 00 01 02
Data output cycle 42 57 02 00 EE FF 00 07
EE FF: setting of output cycle (ms) it must be the integral multiple of 10ms
Byte4-5 EE FF double byte parameter, EE is low 8 bit; FF is high 8 bits
so… I guess 20 msec is 14 00
42 57 02 00 14 00 00 07
Exit configuration mode by the command:
42 57 02 00 00 00 00 02
Now I see data more steadily, now you need to update BetaCopter as the TFMINI driver has been fixed no so long ago, and the error pattern I see was prior to the fix.
@olliw42 have an Issue here, don’t know where to report
The notify node does not cold start.
I have to get into GUI and initiate a RESTART in order to get the display started and showing data
Release: uc4h-notify-v009-4bl-jd.bin
many thx for the testing and the update on the TFMini
I do have now a TFMini myself. I reduced the timeout in the UC4H node somewhat, and I do get clean packets all time, with the TFMini in the default mode (hex output, 100 Hz). I have also flight tested it and I don’t see indication of any unsteady data flow or any error pattern.
With the “old” timeout some of the UAVCAN tunnel packets are indeed weirdly packed, 100Hz and 10ms just don’t fit well, as I suspected, but from looking at the ArduPilot code I would have thought it should just take it (it’s a really simple parser). I guess I should test myself to possibly see what issues you are talking about. With the changed timeout I can’t see any issues, at least there is nothing which triggers me. Maybe you would have a graph of the issues.
I haven’t noticed that the TFMini/RangeFinder driver has been fixed, thx for mentioning.
EDIT: Are you sure the Benewake driver has been changed lately? I just looked at master and what I have in BetaCopter and I couldn’t see a difference…
What does this mean: “the error pattern I see was prior to the fix”? Are you saying that you saw the same error pattern which you saw with the tunnel also before in AC3.6?
display: well, these OLed dispalys are a bit of a thing, I’m afraid, as much as I know there are many similar looking but in fact different kinds of them … I have three of these: https://www.aliexpress.com/item/Free-shipping-Yellow-blue-double-color-128X64-OLED-LCD-LED-Display-Module-For-Arduino-0-96/32233342471.html?spm=a2g0s.9042311.0.0.77664c4d2A0bsh (not from the same seller, bought at different times, all three work) . Unfortunately not a guarantee for anything.
as a first test, could you flash the non-bootloader firmware and see if anything changes?
also, as always, good power supply, USB often isn’t sufficient.
When you write:
I reduced the timeout in the UC4H node somewhat, and I do get clean packets all time, with the TFMini in the default mode (hex output, 100 Hz)
Where do I set this ?
That’s exactly the model I have, I supply with a dedicated 2 Amps supply
Please note that I had to install a capacitor on the serial node as the 2 x TFMINI could not start together because of the power on surge.
All code are uploaded from the GUI as I am testing this ‘‘preferred’’ method
rangefinder: you can’t set this, I did it in the code to see if it would help, and it did. As said before, when I did the tunnel I was thinking that it never would be used for high rate data :D. The timeout mechanism has some weakness, so I’m going to do a quite different logic for the sending. Which will be more robust and not need user interference, I hope. (it’s WIP, you kind of just came too early )
display: hm … I’m a bit clueless what the issue could be, I guess I would test by removing. E.g., would it work without any TFmini? Or with the OLed powered from the Pix, and the TF’s from the external BEC. I mean, is there any minimal configuration which would work.
Yeah, uploading is the preferred method, but for a test pl flash the non-bootloader version.
EDIT: if it’s possible to find a minimal working configuration for the OLed, I quess you’ll start to understand why there is this 5Vext stuff on the gen.nodes