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
There is no delay parameter in new code, so I don have the display starting
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
I will double check tomorrow
Good nite Olli
I have no doubt that you’ll get the same result again, my guts feeling says there is something missing … so, sleeping is a good idea 
good night too
… argh, stupid me, I’ve forgotten to uncomment a line … the 10 ms correspond to 50 ms 
ok, let’s see if I could get it right now 
uc4h-notify-4pp3-startupdelay.zip (62.5 KB)
Yep , it is starting correctly all the time, could you make ad bootloader type so I can test the whole sequence ?
Are you uploading them on http://wiki.jdrones.com/can/firmwares or someone else is doing it ?
Yep , it is starting correctly all the time
great! Thx a lot, this was useful 
could you make ad bootloader type so I can test the whole sequence ?
yep: GitHub - olliw42/uavcan4hobbyists: STM32 32-bit microcontroller based UAVCAN nodes for DIY
Are you uploading them on http://wiki.jdrones.com/can/firmwares or someone else is doing it ?
you’re kidding me, right 
OK tested GOOD
Thanks
I thank you
12345
@olliw42 does the notify read the standard MavLink messages on the CANBUS?
Is there something special we have to do on the FC controler side to get this working ?
I am asking the question because I unplugged the BetaCopter PixHawk and connected my ArduCopter BeagleBone and the notification node is waiting…
there is no mavlink on the can bus (and this isn’t something I would recommend doing)
the UC4H notifier nodes consume the uc4h.Notify message (you should see them in the GUI)
so, yes, there is something special to be done on the FC side, it needs to be running a firmware which is supporting this (it’s like with the tunnel, won’t work either)
need to run for concert now
OK Thanks … enjoy !!
Guys/Gals. may I suggest that future posts, let’s create separate topics under CAN category in here at ArduPilot DAPO under CAN Category
That way other people can follow all developments a lot easier than in one monstrous blog post
1 Like
@olliw42 just received a present 
olliw.eu.uc4h-powerbrick UC4H Power v1.1
I flashed it with latest uc4h-powerbrick-v007.hex
I copied dsdl files (olli) into C:\Program Files (x86)\UAVCAN\UAVCAN GUI Tool\uavcan\dsdl_files\uavcan\equipment\power
I can see the messages headers but there is a crc error:
I just tested with my setup, and it’s working here
looks like some dsdl inconsistency to me
the latest firmware is btw uc4h-powerbrick-v010, and not v007, maybe that’s it already
EDIT: maybe you could post a photo of your powerbrick, it’s quite some time ago I made it for Marc and can’t recall which one it is, just to know
weird, I frankly have no clue what’s going on
the “transfer could not be decoded” message so far I always only got then the dsdl was not consistent with the message (i.e. the id agreed, but not the message format)(and since the id seems to agree you get the name displayed)
I had checked that the dsdl in the git repo is identical to the one I use for the UAVCAN GUI tool, and I just double checked again by explicitely copying the dsdl from the repo to the gui subfolder … it all wroks fine here
could you post the dsdl or give a link to where you took it from?
EDIT: to ensure that you really copy the correct dsdl to the correct place, you could delete the previous dsdl, and start the GUI, it now should not be even able to show the “…GenericBatteryInfo” name in the bus monitor