When I serialized the dump1090-fa dongle I did: rtl_eeprom -s 00001090
similarly for the acars dongle I did: rtl_eeprom -s 00000130
However, when I turn on the bias t in the dongle I get:
Found 2 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000130
1: Realtek, RTL2838UHIDIR, SN: 00001090
Using device 0: Generic RTL2832U OEM
It uses the wrong dongle.
Edit: It’s when I turn on the bias t in the dongle I get the above messages. And I see that the rtl_biast command can only use the index, not the serial number. That’s a problem.
Sorry, late getting back on. Yep dumpvdl2 as mentioned already.
VDL2 is the successor to ACARS, over time expect it will drop off as they start broadcasting the same data (and more) over VDL.
Curious where I could find more information about VDL2 on line. I have found a few things but it’s pretty fragmented. Would like to know how to decode (i.e. read) more of these messages.
Also, is there a list of ground station identifiers (hex identifiers with locations)? I have found a few in Los Angeles and San Diego, but there appear to be many others.
I see that ARINC has a list of documents for this, but they charge like $190 for a PDF or 2X that for a paper copy. Yikes – I guess that’s how they make their money.
On the other side of the coin, I briefly looked at some of the source code for dumpvdl2 – I am impressed. The fact that multiple channels of vdl2 can be demodulated and decoded on a lowly RPi is pretty amazing. And it’s free. Kudos to the author(s).
There is an acars/vdl2 group at groups.io which maintains a list of vdl2 ground stations. The file can be downloaded and added to the dumpvdl2 command string using the option --gs-file /path/to/file (see dumpvdl2 github page for all the details)
Yeah, I was looking at that groups.io. But apparently to access files you need to be a premium member (which has a monthly charge). It used to be free for anyone up to a limit. Not so now.
Have you tried clicking the blue “apply for membership in this group” button on the acars/vdl2 page? All it asks for is an e-mail to sign up to my knowledge, no money involved.
Yeah, I signed up to the group. However, whenever I click on the ground station file it returns me to the main page of the group. Notice how at the bottom of the main page there is an item labeled “Pricing”. If you click on that you get three tiers: Free, Premium, and Enterprise. You only get access to the Files Section if you are Premium or above. If you signed up for a Free access account years ago you might be grandfathered in to getting access to the Files Section.
Sorry that did not work out for you. I wasn’t aware of the pricing changes. I signed up a little less than a year ago and thought everyone would have the same access as I do. Bad assumption from my end.
Do you have access to that Ground Station file?
If so, what does an entry look like in that file?
According to the dumpvdl2 documentation the command is:
--gs-file <file> Read ground station info from <file> (MultiPSK format)
Not sure what MultiPSK format means — just a CSV file or a JSON file?
I was thinking, I don’t really need a file with 10,000 entries from all over the world. I really only need the stations in my area. So maybe I could make my own (very limited) file. To that end, I saw a few stations listed in my area in the group.io you referenced above, namely:
10146A [KLAX Los Angeles International 33°54'N 118°24'W] [Los Angeles, CA]
10346A [KLAX Los Angeles International 33°54'N 118°24'W] [Los Angeles, CA]
10540A [KLAX Los Angeles International 33°54'N 118°24'W] [Los Angeles, CA]
260717 [KLAX Los Angeles International 33°54'N 118°24'W] [Los Angeles, CA]
260718 [KLAX Los Angeles International 33°54'N 118°24'W] [Los Angeles, CA]
260719 [KLAX Los Angeles International 33°54'N 118°24'W] [Los Angeles, CA]
10208A [KSAN San Diego International 32°42'N 117°12'W] [San Diego, CA]
10553A [KSAN San Diego International 32°42'N 117°12'W] [San Diego, CA]
2985D7 [KSAN San Diego International 32°42'N 117°12'W] [San Diego, CA]
2985D8 [KSAN San Diego International 32°42'N 117°12'W] [San Diego, CA]
Some of those stations I have heard. However, I have heard many other stations also. So I could start my own data base if I knew the format of the Ground Station file. Any info would be appreciated.
One suggestion is now that you are a member of the group at the “free” level, message the owners/moderators and ask if there is an alternative way of getting the file. The file is the product of a subset of users time & effort and they have a right to have control over their work, but It seems a bit odd to me that a select set of group users get free access to the file while new folks to the hobby are paywalled. Doesn’t hurt to ask.
Ok, Thanks.
I see the format in gs_data.h and gs_data.c files in the dumpvdl2 GitHub page.
Yes, I can appreciate that some users have created the Ground Station file and have a right to control over their work. But, regarding groups.io, as far as I can tell, only questions from “Premium” members will be answered at this time.
Edit to add:
Creating the Ground Station file is very easy. Now I just need to find additional Ground Stations around here.
That pricing link is for the people hosting their groups on groups.io… If you want to host a group on groups.io then you can get more files space and other advanced facilities by paying the subscriptions. They do not apply to the end users.
Has your membership of the group been approved?
I have only recently joined the group and I can access the files section ok. I only have a free account.
One minor problem with the Ground Station file is the hex value used to represent the degrees symbol on a Mac. The degrees symbol on macos is: 0xC2 0xB0 whereas in the Ground Station file the degrees symbol is just 0xB0. Result is displaying that degrees symbol looks like an infinity symbol on a Mac. Example: 40∞36’N 073∞48’W.
Seems like a simple sed one-liner should fix the above problem like: sed 's\xB0/\xC2\xB0/g' file > file1
however I get the error: sed: -e expression #1, char 12: unknown option to `s'
Any sed gurus out there that know how to fix this? Tnx.
Edit to add: Had an error in sed expression above. It should be: sed 's/\xB0/\xC2\xB0/g' file > file1
However that doesn’t work either. It seems like hex can’t be used, only alpha numeric works. This is on the RPi (Linux).
Final edit:
Don’t over think it – the following works: sed 's/∞/°/g' file > file1
Yes, while most programs can use both device number and serial number, the rtl_biast only uses device exactly as you said in your second post.
My Pi has two devices, both with serial numbers. Both my decoders use serial number, but the RTL-SDR which has bias-t activated by rtl_biast has to be activated by device number.
I am always very careful to check that the device numbers have not changed after making major changes on the Pi. It seems to be stable for normal updates, and only might possibly change device numbers when I have physically swapped out devices. Then I verify the programs are using correct serial numbers and the rtl_biast (if needed) is using the correct device number. Yes, a serial number would be much easier!
For rtl_biast I use a service file which is part of the service file starting dump1090-fa.
Dan,
Well for my setup I only need to turn on the biast for the rtl-sdr used with dump1090-fa. The rtl-sdr used for acars is connected directly to the antenna (no LNA).
I run a little script after startup that stops dump1090-fa, turns on rtl_biast, and starts dump1090-fa again. I don’t always have the acars rtl-sdr running or even plugged into the RPi. However, just in case that rtl_biast is accidentally turned on, I have a DC block (aka a capacitor) between the acars rt-sdr and the antenna. So the rtl_biast in the acars rtl-sdr won’t be damaged if the antenna happens to be shorted out.
I just had another look at rtl_biast on github. There was a merged pull request back in 2019 (linked below) which added support for -d to accept both device number and serial number.
Give your current rtl_biast a try using serial number and see if it works.
The built-in command help as shown below was not updated and still implies only device number is good.
pi@raspberrypi:~/rtl_biast $ rtl_biast --help
rtl_biast: invalid option – ‘-’
rtl_biast, a tool for turning the RTL-SDR.com
bias tee or any GPIO ON and OFF. Example to turn on the
bias tee: rtl_biast -d 0 -b 1
Any GPIO: rtl_biast -d 0 -g 1 -b 1
My current RTL-SDR v3 has the original serial number = 00000001 , which is NOT a valid test because that can be confused as a device = 1.
As a quick test, you can see below that my second (device = 1) has a very unique serial number. It is not a bias-t device, and already in use, so you will see errors below, but you will clearly see that rtl_biast does in fact seem to recognize the unit by correct serial number, and not see it with the second invalid serial number.
Again, ignore the “usb_claim_interface error -6” errors below. This test is only to verify -d serial number usage.
pi@raspberrypi:~/rtl_biast $ rtl_test
Found 2 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 RTL-SDR v3 1: Generic, RTL2832U, SN: 77771111153705700 Unique serial number
Using device 0: Generic RTL2832U OEM
usb_claim_interface error -6
Failed to open rtlsdr device #0.
