@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.
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?
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.
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
@olli
Concerning the Oled Display, it is really a startup delay issue.
I loaded on the bluepill and I need to hit the reset in order to get the display started.
So you need to allow the display to boot before starting the I2C bus, I guess a 20-50 msec delay would be OK
@ppoirier
hm … I generally find it weird then nominally identical setups perform different … anyway, let’s test it, so here a test version which has a parameter StartupDelay, and it is the very first thing which is called: uc4h-notify-4pp-startupdelay.zip (62.6 KB)
EDIT: btw, you now really should get yourself some WS2812B … you could attach one to the notify node and then would also have the indicator led
GREAT!
would you mind to also quickly give this a test: uc4h-notify-4pp2-startupdelay.zip (62.6 KB)
I’ve reshuffled things a bit here + some fixed delay
this was the purpose of it to remove the parameter b ut to keep the function
but your saying it is NOT starting now ??? the delay before the i2c starts is now more than 20 ms !
@olliw42 trust me man, I test your loads and I report
I reloaded the delay version and tested different timing
5 ms too short it is not getting initialized
10 ms and more is OK
I totally trust you
the statement “There is no delay parameter in new code, so I don have the display starting” is however somewhat ambiguous since the 4pp2 has even 20ms !
I’m confused at the result
I suspect there is an additional factor in the game, not just a 10 ms delay