GOES 16 GRB downlink vs GVAR

...
Brett, Got a question for you.
Since we are both using Unimesh dishes 10' in size, what is the distance from the center to the rim of the feed?
I have been running a 45 - 45.5" distance on mine.
As I get up to 46" the gain drops a little.
I ask just to compare notes..
The focal length is 48". So your distance of 45" puts it 3 inches inside the feed. Thats about the same as mine. But the best way is like you already did, by trial and error.

...
Brett you probably know this but I put it up for anyone else.
The coax for both has to be ODD and EVEN multiples of 1/4 waves. It can't be of any random length.

Such as Leg one 1/4 wave (has to be odd multiples 3,5 exc.)
Leg two 1/2 wave (has to be even multiples 2,4,6 exc)...
We disagree here. If one of the coax lines is 1/4 wavelength longer, then the output ends of the coax lines are guaranteed to always be 90 degrees out of phase with each other.
 
Which snack can has that dimension? I looked all over the supermarket and the best I could do was Quaker Oats. But I would prefer a metal can.

Not sure if you have around where you live a or multiple Spanish supermarket (bodega(s)), but the name of the product is called "Cien en Boca". If you can't find them locally (which I recommend), you can get them through Amazon... the seller give you two cans, and they also come with a plastic lid witch is great to keep those bugs out and as much moisture of course. :)

I'm waiting to get another little Spanish snack which should be slightly longer. Will let you guys know of it once I get it, measure it and test it since I've never found the need until now. :biggrin
 
Looking into finalizing the CentOS 6 install and configuration before loading CSPP-GEO so I can get the GLM feed into AWIPS. I agree, I prefer the GRB's resolution (heck even the HRIT) to the re-projected version AWIPS works with. I understand you want to maximize bandwidth/resource usage on workstation and may be local network but at least give the guy an option to opt in/out of higher resolution imagery LOL!!!... I won't complain much since its way better than having nothing.
to get it into awips, you need to run the unidata LDM software on the cspp-geo box, and insert the lightning into a queue to send to the awips ingestor. I added a line in the CSPP-GEO code to do that when GLM arrives. I can find it and paste it if you need it.
 
  • Like
Reactions: KWX
to get it into awips, you need to run the unidata LDM software on the cspp-geo box, and insert the lightning into a queue to send to the awips ingestor. I added a line in the CSPP-GEO code to do that when GLM arrives. I can find it and paste it if you need it.

Please do post the code. I was hoping that once I generate the nc formatted data that I could move it to the manual ingest folder on the EDEX ingestors... So that can't work?
 
Last edited:
The focal length is 48". So your distance of 45" puts it 3 inches inside the feed. Thats about the same as mine.

Good, My formula said it was supposed to be around 46.5" so I was just checking. I figured I was good since the peak is there.

We disagree here. If one of the coax lines is 1/4 wavelength longer, then the output ends of the coax lines are guaranteed to always be 90 degrees out of phase with each other.

Yes, that's right it will be 90 degrees out of phase.
That's how the circular polarization is determined.
The phase shift is + or - determining the rotation.
The signal rotates 90 degrees every quarter wave in time.
RHCP Circular polarization.png

If your combiner receives from both probes at the same instance then they are receiving linear polarization.
Since the signal rotates 90 every quarter wave the seconded probe has to be 90 degrees out of phase from the first (electrically).
That's what the minicircuits combiner does, it shifts the two inputs 90 degrees.
The only way to create a phase shift (that I'm aware of) is a quarter wave longer length of coax or you have to move one of the probes a quarter wave ahead of or behind the other (the probes are still mounted at 90 degrees of each other).
The only time the probe lines are equal is using the splitter/combiner block as it creates the 90 degrees phase shift.

I'm waiting to get another little Spanish snack which should be slightly longer. Will let you guys know of it once I get it, measure it and test it since I've never found the need until now. :biggrin

Glad to see someone still uses the old coffee can. Coffee used to come in those, then they went to plastic. Those lids may only last about a year to 2 then they get very brittle and fall off. Make sure after you make that feed to seal it with some kind of paint or lacquer. Otherwise rust will quickly take over.
 
  • Like
Reactions: KWX
...

Glad to see someone still uses the old coffee can. Coffee used to come in those, then they went to plastic. Those lids may only last about a year to 2 then they get very brittle and fall off. Make sure after you make that feed to seal it with some kind of paint or lacquer. Otherwise rust will quickly take over.

I used aluminum tape to seal the outside but might be a good idea to seal the inside as well even though I have the lid also sealed tight.
 
Got a question for Brett and KWX.
What TBS software are you guys using to configure the tuner and work with GRBStreamer? Looking I am confused.

Also Brett what version of Windows does GRBStreamer work with? I know Win 10 but anything older do you know of?

Also Brett, Lucas updated GRBDump 5 days ago and fixed some bugs maybe that'll help the display issues.

Thanks.
 
Got a question for Brett and KWX.
What TBS software are you guys using to configure the tuner and work with GRBStreamer? Looking I am confused.
The only TBS software is their device driver for the 5927. Besides GRBStreamer, you also need 'streamreader.dll' which was written by a guy in the Ukraine with the handle 'crazycat'. GRBStreamer sets up the tuner when you run it.

Another handy program (by a third party) is 'EBSPro' which can create spectrum graphs and blindscan. There is a remote Android app which works along with EBSPro that you can run on your phone or tablet to peak your dish.

EDIT: Don't forget to use a DC blocker on the input port of the 5927. The TBS sends out about 14 or 18 volts to power an LNBF. It'll fry most LNAs.

Also Brett what version of Windows does GRBStreamer work with? I know Win 10 but anything older do you know of?
Windows 7 works. Haven't tried Vista or XP.

... My GRB receiving system is down now -- waiting for a MiniCircuits 90 degree combiner and a Digital Devices card.
 
Last edited:
The only TBS software is their device driver for the 5927. Besides GRBStreamer, you also need 'streamreader.dll' which was written by a guy in the Ukraine with the handle 'crazycat'. GRBStreamer sets up the tuner when you run it.

Another handy program (by a third party) is 'EBSPro' which can create spectrum graphs and blindscan. There is a remote Android app which works along with EBSPro that you can run on your phone or tablet to peak your dish.

EDIT: Don't forget to use a DC blocker on the input port of the 5927. The TBS sends out about 14 or 18 volts to power an LNBF. It'll fry most LNAs.


Windows 7 works. Haven't tried Vista or XP.

... My GRB receiving system is down now -- waiting for a MiniCircuits 90 degree combiner and a Digital Devices card.

Just as Brett said. I recently added a DC block between TBS and the first stage LNA setup just in case. Thankfully didn't noticed any failing LNAs for the time I had it without it but better safe than sorry.
 
The only TBS software is their device driver for the 5927. Besides GRBStreamer, you also need 'streamreader.dll'
EDIT: Don't forget to use a DC blocker on the input port of the 5927. The TBS sends out about 14 or 18 volts to power an LNBF. It'll fry most LNAs.

Ahh, thanks for the info. Yes, I have followed the instructions for streamreadr.dll so got that.
Didn't think of the LNB power good advice.

There is a remote Android app which works along with EBSPro that you can run on your phone or tablet to peak your dish.

Don't have anything like that so no need there.

Haven't tried Vista or XP.

I can tell you that XP don't. It's not a valid win 32 application. So I will have to come up with another computer to finish this part. Not sure of the time frame on that.

waiting for a MiniCircuits 90 degree combiner and a Digital Devices card.

Well, hopefully you'll be getting that soon.

I recently added a DC block between TBS and the first stage LNA setup just in case.

Thanks as well, Some LNA's already have blocking DC caps in place but it's still a good idea.
 
Well, looks like I got some mix results with the DD card.

As expected, is able to lock without the need to lower the CN into the lower 6dBs like the TBS receiver I have, but it appears its taking it a little while to lock... so resetting the coax to the card helps.

Unfortunately, when it does connect, GRBStreamer is reporting basically ALL packets experiencing sync errors. If I connect everything back to the TBS then no sync errors after locking.

Not sure if you guys know what weather01089 did to his DD card under Windows aside from installing the latest drivers but doesn't appear to be working as I would had hoped. Hopefully he'll be around to provide some input (if any) or anybody else.

I'll try to remove some filters and/or add another LNA and see if it makes a difference ... just in case.
 
...
Not sure if you guys know what weather01089 did to his DD card under Windows aside from installing the latest drivers but doesn't appear to be working as I would had hoped. Hopefully he'll be around to provide some input (if any) or anybody else....
You need to reflash it with the latest firmware to support BBFrames (1.7 or higher). You can get it here: http://download.digital-devices.de/download/firmware/html/firmwareupdate.html#updatewindows

Then it should work fine.
 
  • Like
Reactions: KWX
You need to reflash it with the latest firmware to support BBFrames (1.7 or higher). You can get it here: http://download.digital-devices.de/download/firmware/html/firmwareupdate.html#updatewindows

Then it should work fine.

Thanks for the info. I was able to get it flashed from 1.5 to 1.7successfully, and afterwards I was able to see that I no longer have BBFrames sync errors. Now, if I select CADUFrames from the list then I see sync errors on only CADU but not BB... so this appears to be expected from what I could infer from your statement above Brett.

Interesting enough, I did noticed that I get the same behavior on signal locking as the TBS. I have to get the CN in the 6dB range in order for it to lock almost in an instant.
 
Thanks for the info. I was able to get it flashed from 1.5 to 1.7successfully, and afterwards I was able to see that I no longer have BBFrames sync errors. Now, if I select CADUFrames from the list then I see sync errors on only CADU but not BB... so this appears to be expected from what I could infer from your statement above Brett.

Interesting enough, I did noticed that I get the same behavior on signal locking as the TBS. I have to get the CN in the 6dB range in order for it to lock almost in an instant.
Not sure why there are CADU sync errors, but not BBFrame. What percentage of CADU frames have sync errors? I'll probably get my DD Card Saturday or Monday and will try it here.
 
Not sure why there are CADU sync errors, but not BBFrame. What percentage of CADU frames have sync errors? I'll probably get my DD Card Saturday or Monday and will try it here.

Nice hopefully you'll get it sooner, I like the card, even though most of the installations are in German, but not hard to figure out. LOL.

Now in regards the CADU and BB. The CADU error rate was pretty much over 90%. I found it interesting that the USB TBS receiver would not exhibit this behavior, so figure it had to be either a hardware issue with the PCIe slot or a driver issue or even the DD card (even if I didn't want to admit it). I tried a different PCIe and it appears that at one point there were no CADU errors. Now, not to say that from time to time I would get some sync errors on both BB/CADU, but at least they happened about 1 or 2 every hour, which is still not bad since I would get around the same with the TBS at some points.

Unfortunately moving to a different PCIe didn't yield lasting results and the sync errors on CADU came back. I was using Windows 7 as the test bed for this card, which interesting enough would have issues loading the drivers unless I deactivated at boot time the Driver Signature Enforcement, then it would allow the card to load under Windows 7. I found this very annoying since you have to deactivate it every time you boot the OS and getting a lock was taking longer than I originally thought.

I proceeded to move to Windows 10 Pro, and this time it was a completely different experience. I'm able now to install/load the DD card drivers without the need to disable Driver Signature Enforcement, and as of now, I don't have those high CADU sync rates. I'm still getting some BB/CADU sync errors but at a rate of ~ 0.000000025%. I'm still testing/tweaking, so knock on wood I won't see that weird behavior again of no sync on BB and sync errors on CADU after moving to Windows 10.

Finally, some additional findings in regards this DD card and my 7.5 to 8db CN signal. I notice that if the signal strength is below -55dBm, that the DD would loose lock and stop processing, until I reset the COAX cable and then it would restart most of the time. I added an additional LNA/Filter to get it up to -52dBm and now I'm not having the issue. I must say that it could had been coincidental as I was having that weird issue when it was setup on Windows 7, so it could had been a driver issue all along, but mentioning it in the event someone runs into a similar situation or have input on it.
 
Well, looks like I got some mix results with the DD card.

As expected, is able to lock without the need to lower the CN into the lower 6dBs like the TBS receiver I have, but it appears its taking it a little while to lock... so resetting the coax to the card helps.

Unfortunately, when it does connect, GRBStreamer is reporting basically ALL packets experiencing sync errors. If I connect everything back to the TBS then no sync errors after locking.

Not sure if you guys know what weather01089 did to his DD card under Windows aside from installing the latest drivers but doesn't appear to be working as I would had hoped. Hopefully he'll be around to provide some input (if any) or anybody else.

I'll try to remove some filters and/or add another LNA and see if it makes a difference ... just in case.

I had to use the latest firmware. Other than that, unplugging the coax for 4 seconds or so and putting it back on speeds up the lock for some reason. TURN off the LNA power from the card! I get like .01 percent cadu errors thats it.
 
Nice hopefully you'll get it sooner, I like the card, even though most of the installations are in German, but not hard to figure out. LOL.

Now in regards the CADU and BB. The CADU error rate was pretty much over 90%. I found it interesting that the USB TBS receiver would not exhibit this behavior, so figure it had to be either a hardware issue with the PCIe slot or a driver issue or even the DD card (even if I didn't want to admit it). I tried a different PCIe and it appears that at one point there were no CADU errors. Now, not to say that from time to time I would get some sync errors on both BB/CADU, but at least they happened about 1 or 2 every hour, which is still not bad since I would get around the same with the TBS at some points.

Unfortunately moving to a different PCIe didn't yield lasting results and the sync errors on CADU came back. I was using Windows 7 as the test bed for this card, which interesting enough would have issues loading the drivers unless I deactivated at boot time the Driver Signature Enforcement, then it would allow the card to load under Windows 7. I found this very annoying since you have to deactivate it every time you boot the OS and getting a lock was taking longer than I originally thought.

I proceeded to move to Windows 10 Pro, and this time it was a completely different experience. I'm able now to install/load the DD card drivers without the need to disable Driver Signature Enforcement, and as of now, I don't have those high CADU sync rates. I'm still getting some BB/CADU sync errors but at a rate of ~ 0.000000025%. I'm still testing/tweaking, so knock on wood I won't see that weird behavior again of no sync on BB and sync errors on CADU after moving to Windows 10.

Finally, some additional findings in regards this DD card and my 7.5 to 8db CN signal. I notice that if the signal strength is below -55dBm, that the DD would loose lock and stop processing, until I reset the COAX cable and then it would restart most of the time. I added an additional LNA/Filter to get it up to -52dBm and now I'm not having the issue. I must say that it could had been coincidental as I was having that weird issue when it was setup on Windows 7, so it could had been a driver issue all along, but mentioning it in the event someone runs into a similar situation or have input on it.
also, grbdump has not been updated since 107. Lucas said he will be working on it very soon. Im running windows 7 by the way with the DD card.
 
I had to use the latest firmware. Other than that, unplugging the coax for 4 seconds or so and putting it back on speeds up the lock for some reason. TURN off the LNA power from the card! I get like .01 percent cadu errors thats it.

weather... just to make sure I'm on the same page as you on the power OFF option, I have the following set on the StreamReader.ini file:

LNBPower=0
LNBPwrOff=1

This should suffice right?
 
also, grbdump has not been updated since 107. Lucas said he will be working on it very soon. Im running windows 7 by the way with the DD card.

Great.
In regards windows 7, I guess my PC doesn't like Windows 7 then :eeek. At least so far so good on Windows 10.