All the instructions on getting the DVB-T dongles to receive ADS-B have used Linux as the OS.
While it is fairly easy to get this working in Virtualbox on Windows as a virtual machine, I thought that there must be ways of getting it working natively under Windows.
I want this scenario so I can have the dongle in the loft and feed data via a USB->ethernet hub, but this only has drivers for Windows. Getting coax from the loft to my study is not a task that SWMBO** is going to bear.
Maybe there are ways of successfully installing under Windows but not that I have managed! Even installing GnuRadio is a major task. I've tried installing using a Linux-like shell on Windows (MinGW) and failed to get it working (that took a lot of effort and time). Then I tried from Windows executables after installing loads of dependencies and although it works (sort of) I have no idea how to add the extras to make the RTL hardware work.
I haven't given up, but for now the Virtual Machine approach is simplest! It just works - but with limitations on access.
Ian
** for our non-UK readers, SWMBO = she who must be obeyed
You are a brave man to try this one Ian. I find software messing about pretty daunting and able to consume vast amounts of time.
I don't have a machine that would be likely to handle running a virtual machine that well, but I have a couple of old, laptops that can be wiped and will run Ubuntu with ease. I expect quite a few of us have an old laptop or netbook knocking about. If so, set it up on wireless and put it in the loft with the dongle. Of course, this might be a pain if the thing hung up, unless you could write some kind of start menu script that would kick it off again.
I made a hole through the corner of the ceiling in my radio cupboard for a ten meter USB lead to the netbook handling the linux bit of the system and the swmbo isn't bothered about that since it is my domain. I then monitor the outcome on a windows pc wherever I want in wifi range. I can also monitor on 3g by running Teamviewer on my android phone.
You are correct in how long it takes to build and compile software like this.
I was looking to see if a Raspberry Pi could do the job of feeding data from the dongle down the network. That was worse than trying to make GnuRadio run on Windows. ::)
The subtle differences between Debian and Ubuntu meant the scripts didn't run properly. Once I'd fixed the first bit, it then seemed to be either too slow or another subtle problem to finish. Trouble is, only Debian runs on the ARM CPU - and I have several little boxes with that in but no netbooks :( There are times when the uniformity of Windows has some advantages over Linux and its subtle variations :o
Back to the drawing board (and a look in the spares cupboard) but it keeps the little grey cells active ;)
Ian
Well tried anyway Ian.
However, I think I read that the gr-air-modes routines are pretty processor intensive and that something like a 1.6ghz dual core is needed. That would probably doom the fruit pie.
The netbook I am using has an Atom N280, which is a dual core 1.66ghz chip. Both cores are running at around 90% just decoding and running the Virtual Radar server. I might be able tor educe that a bit if I ran gr-air-modes to supply tcp ip data to a port and used another pc to listen on that one and serve the data. I haven't tried that, but I know you can do it.
I'll share some info with you that I have recently discovered about air modes.
I upgraded my system to the latest revision and you start it witha program called modes_rx now. That version solved the problem of not picking up local planes on take off that I mentioned. But Nick Foster sent me the following line which opens up a new world of possibilities with air modes:
"You can get a list of parameters by typing "modes_rx --help". The defaults should be pretty good for most purposes. The Qt GUI (modes_gui) also lets you play around with most of the parameters."
I have been messing around with the sample rate, the threshold level, and it tells you how to make gr_air_modes output on different ports in different formats of data.
One thing though, I think the latest issue is less sensitive than the one I was running before. Either that, of there has been a coincidental issue that developed in my antenna at the same time as I installed it. I have lost about thirty miles at extreme range now. I improved things a bit by increasing the sample rate to 4,500,000 and reduced the signal threshold to 3db above the noise rather than 5db.
Prompted to put some time aside to try Andy's sw I set up RTL1090 and
tried the E4000 devices I have had here for some time
The results are excellent , bearing in mind these are the slower units
(http://i50.tinypic.com/2z3p89t.jpg) shows a sample image
Message rate is around 60 in Mode S
The main features are available , cleared to alt , wind data etc and
Beamfinder works , although the slow message rate is limiting
This set up passes the raw data test for mlat , but does not function as a
ground station due to the slow data flow , however all in all this is a
massive step forward.
Using a mobile antenna range is very limited but no doughnut effect was
evident ,** Note the image above shows coverage using external antenna
This may well be an ideal second device for local/airfield use
All in all an excellent step forward........congratulations Andy !
You can find out more and , how to set up the dongle by joining
http://groups.yahoo.com/group/rtl1090_english/
Regards
John
PP Support
Thanks John.
For those of us with less brain cells than the average, what's the setup?
Does Andy's software run under Windows? Is PP using raw data or port 30003?
Having struggled with VirtualBox, Ubuntu, GNURadio and GR-Air-Modes, something simpler would be much appreciated. And I wouldn't have got that far without IanH's invaluable assitance.
Hi Mike
Andy has put together a bundle of SW to work under windows
I tried and failed too with the Virtual box/Ubuntu set up , but following the advice in the files section of the 1090 group I managed to get this working on my Vista laptop.
XP didnt want to play but thats probably down to my lack of PC knowledge
Its important to follow Andy;s guide to the letter.
In PP you need to use the Beast tcp input....all that is also explained in the Read Me file within the RTL 1090 folder.
BTW the newer 820 devices are reportedly even better that the E4000 series
Regards
John
Thanks John.
Time to head over to Andy's patch.
I tried the program but couldn't get anything out of it that made any sense to PP. I think the combination of too many options beat me.
Based on what you are showing in your screen shot it could be just what we need to get data from the dongle via ethernet.
Now I need to try again ;)
Ian
Edit: the German Yahoo group that Andy first set up is now defunct so thanks for posting the new Yahoo group. I also see that newer versions of the software are available so that is probably going to make a difference.
Keep us posted Ian. If anyone can crack, you can. ;D
YES - just got a contact plotting in PP. Ok it was only a few miles away but confirms the software works on my system. And yes it showed the assigned altitude.
And another a bit further away!
I think the gain settings look to be critical so much reading of he instructions probaly required.
Now on to the next step.
Ian
Quote from: IanH on November 20, 2012, 05:59:53 PM
I tried the program but couldn't get anything out of it that made any sense to PP. I think the combination of too many options beat me.
Based on what you are showing in your screen shot it could be just what we need to get data from the dongle via ethernet.
Now I need to try again ;)
Ian
Edit: the German Yahoo group that Andy first set up is now defunct so thanks for posting the new Yahoo group. I also see that newer versions of the software are available so that is probably going to make a difference.
I think you'll find the latest sw easier Ian....must be if I can get it working !
The dongles are never going to replace the mainstream Mode S receivers , but they are a cheap and cheerful bit of kit to
put in your pocket and take mobile.
I get the impression that Andy has a lot more refining to do which can only improve the quality of the data :)
There are only little options left in the latest build.
Start with both AGC buttons enabled and you are done for most cases.
RTL AGC should be on in any case.
One thing that is tricky is the installation of the zadig driver. It sometimes fails with "installation pending" message. However, after reboot it usually will either work or a new install will succeed.
You need to reinstall this driver if you use a different USB slot.
Other than that this software is standard Windows and requires about 3% system resources on my legacy dual core PC.
Later developments will be the implementation of oversampling and SDR filtering to get a better detection rate from the very low sample rate of the stick.
I agree about Zadig
On the XP machine I had problems with the drivers and couldn't find the right ones...as a result when running RTL 1090 the programme saw the dongle but couldnt connect [ Error 12]
So I copied the RTL1090 folder I had created and pasted onto my VISTA machine and Bingo...it worked straight away....probably because I had earlier loaded Zadig on Vista and it had taken OK.
Today I ran the RTL 4000 dongle for a couple of hours and noticed an increase in message rate as it warmed up , similar to that seen when using the PGR
Bear in mind this is the 4000 , not the more responsive 820
Message rates increased to well above 100.On the same antenna the SBS3 delivers around 350
This afternoons tests were to check for raw data and evaluate how stable that data was.
The RTL passed the GS/MU test and was set up using a broadband dongle so as not to conflict with my main GS uploading machine , which is presently acting as backup SMU for East Anglia.
The RTL machine was given GS/MU status and raw data was activated.
A target was then selected , in this case an RAF VC10 out in the Irish Sea
A repeating manual mlat was started on the target.
Here's the result
(http://satcomuk.yolasite.com/resources/RTL%20stick%20test.gif)
Checking the PP Mlat log , good levels of data were being supplied by the dongle and the target fixes were good.
I have not yet had chance to assess the quality of the raw data.
Many of the lower cost Mode S devices produce a wild spread of curves which which
can be tamed by "tweeking" each device via the PlanePlotter control console.
Whilst the curves produced by the RTL dongle appeared good , further tests need to be conducted , but will be delayed until I receive the updated "820" unit.
Its interesting to note that the squawk "radiation " function also works well
[ you can see the target change squawk in the last few frames just before it runs out of my range ]
Hi Satcom,
thank you for the great review.
The dongle is in no way different than any other device.
For now the MLAT counter in the packet is set to a fixed value to prevent misuse. I could enable this counter but the resolution is only 500ns and I would need Bev's clearance for this.
Cheers
Andy
Hi Andy
Thanks for the clarification.
I should have one of the 820 T units within a few days , at that stage I'll be able to do more tests and then report back to Bev so that we can consider the raw data side of things....but certainly , as far as a basic sharing device , it seems to do very well ;D
I'll have another attempt tomorrow (finished work for the week) but somewhere in all this testing I've managed to upset Win7 and Zadig.
It isn't seeing the dongle any more. Rebooted, etc. And I've tried running SDRSharp to confirm whether it is there - no success.
So time to move testing to another PC - one of those that I keep "just in case" ;)
Ian
PS Need to order a R820 to get over the lack of interesting items on Amazon's Black Friday "sale". Shoes, makeup, kiddies toys, cookery books, jewellery - FAIL.
You should be able to restore Windows to a point before the zadig installation and then start from scratch.
I have a similar situation here
The 4000E device is working fune , but the newer 820T arrived earlier so I stopped rtl1090
and PP disconnected the 4000E and conncted the 820 expecting all to work OK , but when rtl1090 was started , it could not find the new device error 12
I thought I would then try to reload zadig , but that too failed.
Going back to the 4000E , all works , so at least I can carry out more tests , but not at present on the newer 820T
Too many attempts at installation so not enough restore points to go back to the beginning. Gave up on that PC.
Created a new WinXP virtual machine. Zadig worked fine to install drivers. "rtl_test -t" confirmed working dongle.
Both Mike and I want to run a dongle remotely (in the loft) via a USB/Ethernet hub and not via a long length of coax. So that was the next test. Moved dongle to a USB port on hub. Installed hub control software on WinXP. RTL2832U dongle was shown on hub. Couldn't connect dongle to WinXP until I turned off the WinXP firewall as a temporary fix.
Once connected, RTL2832U appears in Device Manager on WinXP as a USB device. Also appeared in Zadig.
BUT running "rtl_test -t" showed "no supported devices". Not surprisingly RTL1090 gave a similar message.
I was having very similar results with Virtualbox running Ubuntu - the dongle was NOT being presented to the Linux software. I thought this was a lack of Linux drivers for the hub or the transfer of USB signals from Windows to Linux.
Just tried the same on a real Win7 PC with exactly the same results - RTL2832U is present as a USB device via the USB/ethernet hub and appears in device manager but RTL1090 and RTL_test don't see it.
Seems now that the dongle will not run across a USB/Ethernet hub. For me that is a show stopper and I will probably abandon further testing.
Suspect this device is only going to work connected directly to a PC.
Ian
Thanks Ian, glad I'm not alone with the "dongle over Ethernet" issue.
I'll use a laptop upstairs as soon as I have some speare time and see how it compares to dedicated 1090 MHz receivers.
a) Zadig installation is valid for one particular USB slot only. I have failed to install the driver for another slot, too. I can run both E4000 and R820T one after the other, but only in one and the same slot.
b) The device name in zadig is [Bulk-in interface 0]. This is the "libusb" driver. You can find it in System Device Manager as a separate device. If you see something like RTL2832U you have probably installed the TV drivers?
Andy
Thanks Andy...we must have a telepathic link....... I reckon as you were typing your last note I was actually going through the Zadig process again on both XP and VISTA...Bingo both now run the 820T , which is presently on test.
The jury is still out on raw data , the data is there but we are not sure at this stage if it is being contributed to successful Mlats.
I did a long test run for Bev earlier and he's going to have a look at the files later.
Great work....and at least falling foul of the zadig process has taught me to pay closer attention to the instructions :-[
In a different post in this section (to avoid diluting this thread) I mention sending in sending network data from a Raspberry Pi.
The key is that the decoding software can receive data from the IP address running RTL_TCP.
Now if RTL1090 could have that added in, it would give another decoding option, particularly as the output from RTL1090 is more than a simple port 30003 output. ;)
Ian