proto17 / dji_droneid

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

does the drone ID structrue same in lightbridge?

planewave opened this issue · comments

Hello there

I know DJI no longer uses the lightbridge for video transmission, but there are some third parties still using it. do they transmit the drone ID too? if so, is the packet structure the same?

thanks

Hello! I see on signals of Inspire 1 and it is not same frame.
image
It has 1.2-1.5Mhz bandwidth.
And i did experiments with aeroscope, and when i power on RC, aeroscope see this.
When i power on only UAV, aeroscope doesnt see this.

@proto17 Any ideas?

@planewave No, aeroscope listen not only ocusync. Lightbrige and wifi too.
Inspire interacts with rc by lightbrige.
And aeroscope sends message only, when rc is on. And when only rc is on.
May be rc sends broadcast always.
What is your nick in WeChat ?

mi_nombre @lobart
by the way, are you sure that is the drone remote ID signal, not just the RC signal?

@lobart the signal you posted doesn't appear to be DroneID in bandwidth or structure. That signal looks like it has a very short repeating preamble which isn't normal for DroneID. My guess is that's the uplink signal from the controller to the drone. Most of DJI's product line that isn't WiFi will hop on every transmission for the uplink, and they tend to be very narrow in bandwidth (~1 MHz). So that's a pretty good way to tell if you're looking at the uplink or some other part of the system.

@proto17 @planewave
No more signals, only this, and aeroscope see RC. And aeroscope see RC on same frequencies like i write this signals.
May be it is not Drone_id, but in this packet there are information like drone_id

@lobart
My WeChat ID is mi_nombre
Let's see what we can find

@proto17 so do you have any idea regarding the DJI drone ID in Lightbridge?

@planewave it's definitely possible that the uplink contains some of the same kind of data that the DroneID frame does but not actually be DroneID. Think of it like a side-channel that sends additional arbitrary commands to the drone along with the stick control values. I have seen information come off of Lightbridge controllers like position, drone name, mission information, etc. But have not seen anything like DroneID over the Lightbridge uplink. It's important to know that I haven't looked at Lightbridge for several years, so it's possible it was updated to also contain DroneID.

Hi @lobart , since you have access to the Aeroscope, I have an idea to verify our assumption. You can replay the suspicious narrowband signal at the original frequency using your SDR and see if it can be picked up by Aeroscope. If so, please share the date and I will see if I can decode it

Hi everyone,
I have a Phantom 4 Pro with Lightbridge, and I was trying to decode the droneID packets coming from it. Analyzing the entire 2.4 and 5.8 GHz spectrum there is no sign of the bursts. It seems the only signal emitted by the drone is the video downlink. Is it possible that the drone ID information is coded inside the video downlink stream? The alternative is the drone ID burst is transmitted by the RC as suggested, but it really makes no sense to me that a "drone identification" packet would be sent from the RC.

@arglas864 lightbridge has not drone id.

@lobart the Aeroscope clearly supports the detection of the lightbridge drones. you can find them in this list
areoscope_type_20221116.txt

@arglas864 I am facing the same difficulty. it is likely the drone ID is inside the video link. but no matter what, the first step will be unpacking the drone or RC's packet and extracting the payload. It is a very difficult reverse-engineering task given very little information.

what I know is that it is loosely based on the 802.16e (mobile WiMax) protocol, some questions I have are

  1. how the pilot subcarriers are distributed for the drone signal?
  2. how the data subcarriers are interleaved or randomized or it is randomized before encoding?
  3. is it convolutional coded like that in 802.16e?
  4. which part is CRC protected so we can confirm the decoding is corrected and if the CRC is the same as that in 802.16e?
  5. in addition, the drone seems to have MIMO (MISO?) implemented. How to decode that?

Above all, assuming we do manage to decode the packet, how can we say a drone ID is in such a packet?
If I had access to an Aeroscope, like what I suggested to @lobart, I would replay a few certain prerecorded packets using SDR and see which packet can trigger the Aeroscope's detection. once we pin down a specific data packet, we can then go to the decoding process.

Hi @lobart , since you have access to the Aeroscope, I have an idea to verify our assumption. You can replay the suspicious narrowband signal at the original frequency using your SDR and see if it can be picked up by Aeroscope. If so, please share the date and I will see if I can decode it

Hello friends. I have the opportunity to check the recorded signal on the aeroscope. I have HackRf

@planewave did you have any luck decoding the downlink yet? have you been able to get an idea about the randomizer used?

@anitasusan Sorry, I haven't worked on it for a long time. no conclusion.