GOES 16 GRB downlink vs GVAR

[weather01089]

Yep, that was something Ayecka told me when I was in touch with them.




That's plain ridiculous that it takes that time to lock.
+ they (Ayecka) said they weren't seeing issues like that when I was talking with them.
Yep, They don't care to mess with it. Sooo why are they making it?
Again, Oh well.


Nice view of the GLM.
Ray what software suite are you using to display the files?[/QUOTE]

Im using python scripts to generate images on a seperate computer running dual 10 cores lol. You can generate a few on the
same server as CSPP-GEO, but it gets bound up if you do too many.

 

[weather01089]

Had the same thought, but thought to first give it a while to see how it works out without it and then try another DC block to see if its defective somehow.

You know, I don't think the setting in the CFG file doesn't work. It won't turn off the power on the TBS receiver.

In regards GOES 17, is almost at 89.5. It should be there later tonight or tomorrow AM. Hopefully it'll be close enough to you by the time they start activating sensors, so you can start tweaking your setup up.

The DC is off, Im using a Nooelec bias tee to power the LNAs

 

[weather01089]

Quick question for you Brett, Are you using a "TEE"
to combine the coax cables?
If so..Did you calculate the TEE's length into the combiner?
Yep I, knew that your were reusing that but I made some suggestions for everyone on here.
Again lessons I've learned.

You cannot "tee" the cable, you have to feed each into a tuner, which generates a stream. Then feed the streams into ingest software (Uses UDP different ports for each)

 

[weather01089]

You cannot "tee" the cable, you have to feed each into a tuner, which generates a stream. Then feed the streams into ingest software (Uses UDP different ports for each)

Each feed has different bands on it.

 

[weather01089]

Thanks for the response Ray,
I was wondering if you were going to tell me.
That computer you have there, are you using it for the display machine as well or just the data processor?
If you're using it for both then that thing is loaded down.
How much RAM do you have installed?

64gb ram on the ingest, 128gb on the one Im doing images on. You can process SOME images on the ingest but it gets bound up
if you do too many.

weather01089 - Hopefully Lucas fixes the issues with GRBdump, its far superior.

Has anybody contacted Lucas and asked what he was running to get the GRBDump to work correctly?
See if it can be reproduced on another machine.
Seems to be a strange issue since KWX looked at the details of the hardware usage due it the software's lag time.
I think it would be nice if Lucas would make his software spit out the Netcdf files OR the images.
Kinda like weathermessage does with the NOAAPORT images.
Seems since it already does a portion of that now, why not output the Netcdf files, OR binary files.
But it's nice he did as much as he did.
Regardless there is a lot of data coming through those links.

Lucas indicated he would look at it but hasnt had time as of yet. Im using cspp-geo. Grbdump definately has issues with it getting bound up
image processing. I reduced it to a few bands on one feed and it works well, but as soon as you add more, it has issues keeping up. Its definately software
since I can run cspp-geo with both feeds ingesting on the same box. cspp-geo produces netcdf files.

 

[weather01089]

Thanks for the response Ray,
I was wondering if you were going to tell me.
That computer you have there, are you using it for the display machine as well or just the data processor?
If you're using it for both then that thing is loaded down.
How much RAM do you have installed?

64gb ram on the ingest, 128gb on the one Im doing images on. You can process SOME images on the ingest but it gets bound up
if you do too many.

weather01089 - Hopefully Lucas fixes the issues with GRBdump, its far superior.

Has anybody contacted Lucas and asked what he was running to get the GRBDump to work correctly?
See if it can be reproduced on another machine.
Seems to be a strange issue since KWX looked at the details of the hardware usage due it the software's lag time.
I think it would be nice if Lucas would make his software spit out the Netcdf files OR the images.
Kinda like weathermessage does with the NOAAPORT images.
Seems since it already does a portion of that now, why not output the Netcdf files, OR binary files.
But it's nice he did as much as he did.
Regardless there is a lot of data coming through those links.

Lucas indicated he would look at it but hasnt had time as of yet. Im using cspp-geo. Grbdump definately has issues with it getting bound up
image processing. I reduced it to a few bands on one feed and it works well, but as soon as you add more, it has issues keeping up. Its definately software
since I can run cspp-geo with both feeds ingesting on the same box. cspp-geo produces netcdf files.

I tried grbdump on all kinds of hardware, you cannot give it enough CPU lol.

 

[KWX]

I tried grbdump on all kinds of hardware, you cannot give it enough CPU lol.

grbdump can become quite a handful.

I'm quite sure if Lucas can get the ingest and post ingest (data generation process) compartmentalized so they can be independently installed/ran (if needed) on different "servers" then it will greatly help and avoid having to re-engineer quite a bit of the code... at least in the short term.

 

[GOES 12 GVAR user]

So far both TBS and DD running as expected, by the way, I'm splitting that single feed into 3, one for the TBS, one for the DD, and one for one of my SDRs for HRIT. Thankfully still getting 9.7 to 9.8dB on both TBS/DD with the 8.5 footer.

You're splitting the output (one stream), and that can be done. The problems begin to rear their ugly head when you split the input before the combiner to get both streams RHCP/LHCP.

I wish these DVB devices had a hardware switch to turn off DC power. It might be possible to cut the trace on the circuit board where the power is inserted into the line, and avoid the need for a DC blocker altogether.

That's one of the advantages of the Novra receiver as it has an area of the settings that you can turn off the LNB power.

 

[N6BY]

You cannot "tee" the cable, you have to feed each into a tuner, which generates a stream. Then feed the streams into ingest software (Uses UDP different ports for each)

That was an experiment with a 2 probe can antenna and a 90 degree combiner (like KWX is using). I think GOES GVAR meant to say 'combiner' instead of 'tee'.

 

[GOES 12 GVAR user]

Im using python scripts to generate images on a seperate computer running dual 10 cores lol. You can generate a few on the
same server as CSPP-GEO, but it gets bound up if you do too many.

Yep, That why I made the suggestion of keeping the GRB ingest computer by it's self. It takes a lot of processing power and memory to display this data due to it's size and complex calculations.
A GRB earth station consists of a computer for ingest and a computer for display. The typical way is the ingest computer is a server or the storage drive is on a server (the idea I have for mine).

 

[GOES 12 GVAR user]

You cannot "tee" the cable, you have to feed each into a tuner, which generates a stream. Then feed the streams into ingest software (Uses UDP different ports for each)

Each feed has different bands on it.

This is true for the septum feed design.

I think GOES GVAR meant to say 'combiner' instead of 'tee'.

Correct, that's when we were talking about making the hybrid combiner via coax and a "tee". It involves the the 2 probes to be combined to get circular polarization (single stream). The same that's done when using OSCAR's or moonbounce.
With the septum feed there is no need of combining as the septum feed does RHCP/LHCP by design.

 

[GOES 12 GVAR user]

Weather 01089
Ray, what's style of septum feed do you have?
Use a choke/ matching ring with it?
Is it round or square? A picture would be nice as well if you would.

 

[KWX]

You're splitting the output (one stream), and that can be done. The problems begin to rear their ugly head when you split the input before the combiner to get both streams RHCP/LHCP.


That's one of the advantages of the Novra receiver as it has an area of the settings that you can turn off the LNB power.

Which I could take the that output and split it back for recombination lol... darn it.

 

[GOES 12 GVAR user]

64gb ram on the ingest, 128gb on the one Im doing images on. You can process SOME images on the ingest but it gets bound up
if you do too many.

Thanks for the info, I now know what I need for the ingest computer.

I tried grbdump on all kinds of hardware, you cannot give it enough CPU lol.

It was worth asking, Lucas's software is again doing a LOT when trying to display all the data coming from both streams.

I'm quite sure if Lucas can get the ingest and post ingest (data generation process) compartmentalized so they can be independently installed/ran (if needed) on different "servers" then it will greatly help and avoid having to re-engineer quite a bit of the code... at least in the short term.

I'm not sure how far Lucas was planning to take his software. But he does have a great start to make a similar platform to CSPP GEO if he decides to go that far.

I am going to leave a message for the guys at the CSPP GEO, I am going to make a request for the software to have an option to take BBF's instead of CADU Frames.
Considering what Brett did for his streamer I would think that they could make CSPP GEO take BBF's without too much extra work.

 

[GOES 12 GVAR user]

Which I could take the that output and split it back for recombination lol... darn it.

I still plan to try different ideas for receiving both polarization's but my main focus is getting a usable stream going. I have another idea for a receiver here that I plan to put in motion. It's a card style so I would only be able to send the dump to Brett for analysis. If it works there yet may another option for hardware to use for GRB reception that's cost friendly.

 

[N6BY]

...
I am going to leave a message for the guys at the CSPP GEO, I am going to make a request for the software to have an option to take BBF's instead of CADU Frames.
Considering what Brett did for his streamer I would think that they could make CSPP GEO take BBF's without too much extra work.

Is this because you have found a standalone DVB receiver box that outputs BB Frames? The only existing one I know that comes close is the Ayecka, but it outputs an extra 4 bytes of junk along with the BBFrame. Also it is difficult to lock and only supports one input.

Quorum's rack mount GRB-200 receiver outputs CADU frames. It lists for $17,995.

 

[GOES 12 GVAR user]

Is this because you have found a standalone DVB receiver box that outputs BB Frames?

Not exactly, I have found standalone DVB receivers that are far cheaper than the Quorum receiver.
What I'm looking at is the output of CADU frames is not very common at all among the DVB receivers unless you want to get to 5 grand or more price tag.
I stated that the output of BBF's is far more common and much cheaper as well available to the general user.
Yes, you're right that many of these receivers don't just output the BBF we desire for this, but it does make it even easier in the future if there are receivers that start to give you options for output data types. For example the Novra S400 if it comes to pass.
It also stems from GRBDump as it takes BBF's. It was my thought that it will make CSPP GEO software more compatible in the future with that option.
You're streamer will still be needed in most cases, but again it would open the options up in the future on the hardware side of things for more mfgrs to make semi compatible hardware.
What I asked was the software to have an option to accept BBF's as stated in the GOES R PUG.
Will they do it? I don't know but I figured it couldn't hurt to ask.

 

[KWX]

Not exactly, I have found standalone DVB receivers that are far cheaper than the Quorum receiver.
What I'm looking at is the output of CADU frames is not very common at all among the DVB receivers unless you want to get to 5 grand or more price tag.
I stated that the output of BBF's is far more common and much cheaper as well available to the general user.
Yes, you're right that many of these receivers don't just output the BBF we desire for this, but it does make it even easier in the future if there are receivers that start to give you options for output data types. For example the Novra S400 if it comes to pass.
It also stems from GRBDump as it takes BBF's. It was my thought that it will make CSPP GEO software more compatible in the future with that option.
You're streamer will still be needed in most cases, but again it would open the options up in the future on the hardware side of things for more mfgrs to make semi compatible hardware.
What I asked was the software to have an option to accept BBF's as stated in the GOES R PUG.
Will they do it? I don't know but I figured it couldn't hurt to ask.

Definitely doesn't hurt to ask. Hopefully they'll answer your question and please do let us know what they say.

 

[KWX]

Interesting behavior I experienced this AM from GRBStreamer. It all off the sudden stopped streaming. It wouldn't' start streaming, until I closed GRBStreamer and restarted it. Just the first time I experinced it.

 

[N6BY]

Interesting behavior I experienced this AM from GRBStreamer. It all off the sudden stopped streaming. It wouldn't' start streaming, until I closed GRBStreamer and restarted it. Just the first time I experinced it.

Maybe it lost signal and was unable to recover (either the program or the TBS5925)? I would try to reproduce and fix the problem here, but I don't have a good enough signal yet.