Added a function that retrieves RSSI values from Mode-S messages received by PiAware devices

[kirth123]

PiAware devices (developed by FlightAware) receive and process Mode-S messages from aircraft. As a software engineer intern at FlightAware, I learned how to decode the messages processed by PiAware devices and retrieve their RSSI values. RSSI stands for Received Signal Strength Indicator and it indicates how strong a radio signal received by a wireless device is. The RSSI values developed by my function will generally range from 0 to -50 with 0 being the signal at its theoretical peak. The RSSI values returned will be relative to the maximum peak it can achieve and will be in terms of dBFS units.

[xoolive]

As far as I understand the documentation, the rssi is given as a percentage by this line.

[xoolive]

This is often referred to online as dBm, and is opposed to PmW (what you name power). But you seem to assume that the power is that percentage squared??

[kirth123]

Let me clear up my methodology. My company uses a device called PiAware which emits RSSI values as linear voltage measurements. This means that each measurement is essentially sqrt(power) * 255 (as power is proportional to voltage squared). I should note that PiAware records power as a float within the range of (0.0, 1.0) with 1.0 = full range on the ADC. My company wanted me to convert this value to a dBFS power value. To do so:

1. we get the raw 0-255 byte value (raw_rssi = mm[7])
2. we scale it to 0.0 - 1.0 (voltage = raw_rssi / 255)
3. we convert it to a dBFS power value (rolling the squaring of the voltage into the dB calculation)

Essentially, we have performed the equation 20log10(signal/255). It's important to note that we used dBFS (a relative unit of measurement) compared to dBm (an absolute unit of measurement).

[xoolive]

Thanks for the explanation. I am not very familiar with these aspects. I am just wondering whether those variable names are appropriate. Or what would be relevant comments in the code.

From few references I checked online, rssi is often defined as the percentage that you compute (see wiki), but you named that percentage voltage (but then for me there's a dimension problem if we call that voltage, no?) Also maybe name the final value dbfs or rssi_dbfs?

The question is also whether we are following the beast format standard or just reverse engineering this:

https://github.com/flightaware/dump1090/blob/a80ba8f82a74c90a29619ddbc10909c561198541/net_io.c#L473

So what you call voltage is the signalLevel in this code?

But that signalLevel is computed as the average of the magnitude of the I/Q samples along the message divided by 65535 * 65535 (assuming you get the samples as int16*int16, makes sense). So why voltage? That's really just a ratio (between 0 and 1, further encoded as an int8).

Reference:
https://github.com/flightaware/dump1090/blob/a80ba8f82a74c90a29619ddbc10909c561198541/demod_2400.c#L381

Also, it would probably make sense to return None when the value is 0xff, according to the standard and to the implementation there.

By the way, do you understand that implementation here? Why the sum??

https://github.com/flightaware/dump1090/blob/a80ba8f82a74c90a29619ddbc10909c561198541/net_io.c#L1859

[xoolive]

(That's really thinking aloud, I am only trying to understand... Sorry if that is annoying)

[kirth123]

I'm glad you asked these questions. I agree with a lot of the changes you suggest concerning renaming the variables and changing the comments to be more descriptive and plan to make them in my next commit. I consulted the developer of the dump1090 library (Oliver Jowett) for this project and this is the methodology he proposed. I can ask him the questions you raised. I feel in some ways that I'm reverse engineering the methods used by dump1090. I might need to figure out a way that works for all devices rather than just those used by dump1090.

[xoolive]

Thanks for taking it positively. Maybe we keep it as is in the end, but at least we will know why :)

[xoolive]

why do you provide those files?

[kirth123]

they were provided in the original git repo, so i kept them. i might have accidentally deleted them in an earlier commit and then added them back again in a later commit, thus showing up as an addition to the branch

[xoolive]

ok but there's a huge unnecessary diff on these files

[kirth123]

Can I create a new branch from master and add only the file I want to change (tcpclient.py) to my git index? This way when I try to merge this new branch to master it will avoid all the issues we have with the csv files and modeslive.py. Another way I could fix this is by reverting all the commits for this branch and doing the selective addition.

[xoolive]

You can also edit the past commits and remove the unnecessary files from there.
Check git rebase --interactive command and pick edit for the guilty commit. Then you will need a git push --force

[kirth123]

i dropped all the previous commits using git rebase and committed a new one that should be good

[xoolive]

why do you change permissions on this file?

[kirth123]

I've removed this file from my branch so we don't have to worry about file permissions anymore.

[xoolive]

you removed more than your file in your last commit...

[kirth123]

I did that on purpose. I only changed the tcpclient.py file, so I thought that I should only include this file in my branch to avoid confusing you.

[xoolive]

Look at the "File Changed" tab: every file with a red [-] next to it will be removed if we click "Merge". By mistake, you pushed a commit that removes all those files (so basically the entire code base).

[kirth123]

Alright I added all the files again to the branch and made sure the file permissions for all the files are 100644. i'm not even sure why that one file had different permissions in the first place

[junzis]

thank you @kirth123 and @xoolive for the pr