Add transmitter capabilities

[janusw]

Carrying over an idea from #13 (comment):

Wouldn't it be a good idea to add such a transmitter capability to the Android receiver app, so it could (optionally) also act as a "drone simulator" and transmit data to other instances of the app? I imagine that this might be very useful for testing and experimenting.

[lukasbrchl]

Well, I still don't see any added value over the nRF Connect for Mobile advertiser mock. You could add there a new record with the Manufacturer Data field and add a payload with dummy data. You could create multiple records with multiple technologies + frequencies, so you can simulate the DRI payloads. But I don't think you would need real data (e.g. position from the phone). This is a simple solution that is already available. Someone has to create the valid hex payloads though.

[janusw]

Well, I still don't see any added value over the nRF Connect for Mobile advertiser mock. You could add there a new record with the Manufacturer Data field and add a payload with dummy data. You could create multiple records with multiple technologies + frequencies, so you can simulate the DRI payloads.

Ah, ok. That would actually be a good first step, at least. Maybe it would be worth to add some short documentation on how to do that somewhere ...

But I don't think you would need real data (e.g. position from the phone).

Well, technically you don't need real data for testing. But it can still be useful to do some more realistic tests with an actually moving target and data that is changing over time. The method above would just repeatedly transmit some 'static' payload data AFAICS.

With real data, one can do extended testing of signal strength and signal range as well as latency etc. One could even attach a smartphone to a real drone (instead of using a dedicated HOD), for people that do not have access to such devices (yet).

[friissoren]

To me it sounds like a good idea, if you have the time, energy and interest in implementing it. Typically people find methods to use things in entirely different ways than you originally thought.

This might not completely work as a "poor man's" broadcast add-on, since putting an old smartphone on the drone as a transmitter probably wouldn't meet all of the broadcast Tx strength requirements defined by the EU and US rules (and would be very heavy), but for activities of development, experiments and studying drone ID, this would certainly be a value add.

Even just documenting what UUID, bitcodes etc. to hard-code into the nRF advertising app for static transmission would be useful.

[janusw]

To me it sounds like a good idea, if you have the time, energy and interest in implementing it. Typically people find methods to use things in entirely different ways than you originally thought.

The interest is there (I would definitely use such a tool). I cannot promise it, but I may try to look into it ...

This might not completely work as a "poor man's" broadcast add-on, since putting an old smartphone on the drone as a transmitter probably wouldn't meet all of the broadcast Tx strength requirements defined by the EU and US rules (and would be very heavy), but for activities of development, experiments and studying drone ID, this would certainly be a value add.

Sure, it will not replace dedicated hardware, but that's not the aim anyway.

Even just documenting what UUID, bitcodes etc. to hard-code into the nRF advertising app for static transmission would be useful.

Absolutely. I someone has done this, it would be useful to share the instructions.

[lukasbrchl]

@janusw I copied the raw payloads from our device advertising via BT 5 LR. If you want, you can try to plug them into nRF Connect Mocker and do a simple test if the receiver app sees it. I would do it myself, but I don't have a second phone right now.

Telemetry:
0x1E16FAFF0D00102038000058D6DF1D9055A308820DC10ACF072803D20F0100

Message pack with Basic + System + Operator ID (empty one):
0x5316FAFF0D00F0190300123135393633353236353631303035323838393500000000500000000000000000000000000000000000000000000000004004FDC5DF1DA584A308010019000000001000000000000000

[lukasbrchl]

Btw, we also have a Sniffle Bluetooth sniffer available, so I can then check the payloads from the smartphones if needed.

[friissoren]

That actually worked :-)

In the test data you gave, you have to ignore the length (0x1E) (the app calculates that) and the specifier for 16-bit UUID (0x16) and the UUID needs to be entered as 0xFFFA (endianess conversion) but after that you just put in the binary drone ID message data.

I didn't try with the extended/long range message pack but at least for the single BT4 advertising it worked. It showed up as a static drone in the receiver application.

[friissoren]

Additional observation: If I stop and start the transmitter, the nRF app assigns a different MAC address. This way you can add many devices to the list view in the receiver, although only one of them will be actively receiving data.

[lukasbrchl]

Additional observation: If I stop and start the transmitter, the nRF app assigns a different MAC address. This way you can add many devices to the list view in the receiver, although only one of them will be actively receiving data.

Hmm, that might be a little trouble. I would expect that if you add multiple records they will all have the same MAC. Thanks for testing this.

[janusw]

That actually worked :-)

In the test data you gave, you have to ignore the length (0x1E) (the app calculates that) and the specifier for 16-bit UUID (0x16) and the UUID needs to be entered as 0xFFFA (endianess conversion) but after that you just put in the binary drone ID message data.

I didn't try with the extended/long range message pack but at least for the single BT4 advertising it worked. It showed up as a static drone in the receiver application.

FYI, I have also managed to reproduce this (but only via BT4 was well). Could see it both in the nRF app and the OpenDroneID receiver app. Thanks!

[friissoren]

Works also for the Coded PHY, assuming you have two devices that supports that:

[lukasbrchl]

If anyone ever needs to do a simulation with nRF Connect, here are some dummy payloads for BT4 Legacy
Basic ID: 0x0D0000123135393633353236353631303035323839343500000000
Telemetry: 0x0D00102038000058D6DF1D9055A308820DC10ACF072803D20F0100
Operator ID: 0x0D0050004E554C4C00000000000000000000000000000000000000

This is how you plug them into nRF Connect:

And this is how you can see them in ODID app. Please note that they are shown under different rows since nRF Connect uses different MAC addresses for each advertisement payload.

[friissoren]

Somewhat related investigation here:
opendroneid/opendroneid-core-c#42 (comment)

[friissoren]

The first baby steps for doing WiFi Beacon transmission from Linux (RaspberryPi4 at least) are described here:
opendroneid/opendroneid-core-c#42 (comment)