Here4 UART Sniffing while connected via DroneCAN

Hi
With the Here3 we are able to have the GPS connected to the cube via DroneCAN and listen to the GPS data in parallel over UART with our flight monitoring unit.
I’ve read that only 3.3V on the I2C activates the Here4 to communicate over UART. How can we enable an additional GPS data output on the Here4 UART?
Could you provide us with a firmware that is capable of doing so or else provide us with the necessary documents (block diagrams, schematics) so we can write the code ourselves?

@mm-dbr the firmware project running on Here4 is available here: GitHub - CubePilot/GNSSPeriph-release

As to answer your question regarding connecting to Ublox module onboard over DroneCAN, you can follow these steps to do so. Disregard firmware update part of the steps, just follow the connection part.

Thanks for the quick reply and the links, but i don’t think you’ve completely understood our issue.
Currently, the Here3 is connected over DroneCAN to the FCU and the GPS UART TX line is connected to another uC, where we can monitor the GPS data additionally. We had to configure the UART to output the GPS data over UART for this to work. Now we would like to do the same with the Here4, but since the F9P is not directly connected to the UART of the Here4 10Pin JST, we need to find some way to make the Here4 STM output the GPS data on UART as well.
From Github it looks like you pass-through the UART if the I2C line is attached and then the GPS via DroneCAN is deactivated. The simplest solution from our point of view is for you to add a configurable transmission pass-through of the TX line (not the RX to prevent interference) from the F9P module to the UART of the Here4 connector, with the DroneCAN interface still active. With this, we (and others) could still benefit from firmware upgrades as well, without internal code adaption with every update.
The other option would be the following:
We would use the M4 processor to handle the UART-forwarding to the UART output on the connector. Therefore we’d need a block diagram or a schematic. But we’re not that familiar with the Arducopter libraries that you’ve linked in your code. And the baud rate between the F9P and your STM H7 is very fast and this could complicate things for our solution as well.
Is this feasible and if so, can you provide us the documents? We could also set up an NDA if necessary.

@mm-dbr Usually the requirement for Here4 operation when using Serial and I2C is to be backwards compatible with old mechanism. This also requires us to make sure that Here4 main firmware gets out of the loop to manage ublox configuration in this case. Otherwise the FC connected over Serial will end up fighting Here4 main firmware. I2C is the easiest way to detect if the FC is using this interface and hence was used for this switch.

Your requirements are not usual way the Here4 will be used but can be fulfilled with minor changes to the code. I will see if I can find time to add this support.

If you want to have a go at it I would welcome your PR as well. Basically you can add code to this file GNSSPeriph-release/AP_Periph/serial_tunnel.cpp at release · CubePilot/GNSSPeriph-release · GitHub.
Currently it only sets up serial monitor when it receives Tunnel packet. You will need to add a parameter to setup this up inside the send_serial_monitor_data method when enabled and push the data buffered by monitor loop over to the serial port you want. You can also add option to set the serial port to the same baud rate as the F9P serial port or use parameter to set it to a value you want.

1 Like

Hi Siddarth
Our software team is currently looking into this issue and is wondering, if there is an SWD or JTAG connection available on the Here4, which we can use for programming?

Yes. The tiny connector on PCB you’ll see is for swd. You’ll have to open case.

Thanks @RedbullF1!


This one? and if so, do you know the pin assignment and the connector type?

Yes. Could be below pinouts if they maintain standards with cube debug port.

Yes that is the correct pin out. It’s been same for a long time.

Best way would be to modify GNSSPeriph-release project to do what you need.