GOES 16 GRB downlink vs GVAR

So I made a septum feed for 1686.6 MHz last night, which I plan to try out before the move from 89.5 to 75W. The septum feed is quite large - approx. 18"x4.5"x4.5".

Great, keep me informed of the outcome of that feed. Yes those feeds are large but I think with what's gained in terms of benefits it's worth it.
The OK1DFC feed is a fine feed. My feed is of a round design and since I haven't been able to find the material I need I haven't been able to build the prototype yet. Without testing it I won't put up any info on it.
I am kinda surprised that Ayecka's reciever doesn't already support that.
When I search the Ayecka DVB-S2 receiver I also come up with the Novra S300 and EUMESAT.
EUMESAT is Europe's weather satellites and I don't think that they are open for reception as NOAA's are. As a result the proprietary nature of the down link the mfgrs can charge what they want for the hardware as there is no other way of getting it. Himawari is definitely that way, software as well.
So we are dealing with an industry that pretty much has all to it's self and works with Gov's and Universities that can (and will) pay these amounts.
I really think that most DVB-S2 receivers can do this (generic) data but the firmware has to be set up for it.
I think that cheap china box could do it if the firmware was set up for it.
I'm glad that at least one of the mfgrs are giving OSP a try. Trends start here.
Thanks TBS for letting OSP have the tools to try this.

I offered to help, but they are not allowed to share the TBS source code.

I figure that TBS source code is under lock and key. There are very likely some very stiff rules for being able to allow the use of that code as that's what TBS markets from.
But if (when) OSP gets it to work, TBS might write in into their code on other hardware making it possible to use more then just the PCI card.
Other mfgrs could follow...Wait and see.
I will say this.. I don't see the generic stream going away anytime soon and has even more possibilities in the future, for us that's a good thing.
I don't think it super hard to process the GRB stream but it's resource intensive depending how much you want.
On another note my new Novra S300 will be here in a day or less, finally shipped as I had to wait for it to come from Canada.
 
However, it did pick up a good signal at 1694.1, which is HRIT.

That's kinda strange as HRIT is linear polarization.

Was quite surprised to see Outernet coming in with an SNR of 35 db !!! That signal strength completely blows away my previous attempts a year ago

Glad it works for that, but not what you want exactly.
The reading I have done about these that they are very fussy about the dimensions. The septum's dimensions can make a very large difference in signal.
Again since I haven't made one yet I can't say. But I don't see a reason why it wouldn't work.

or they shut off GRB ahead of the scheduled move on the 30th, or ???

The GRB signal is still being sent. If you keep wondering about that go to here (link) and look at the UTC time stamp as these guys get as close to realtime data over the web as it gets.
 
That's kinda strange as HRIT is linear polarization. ...
Septum feeds are good for linear too.

...Glad it works for that, but not what you want exactly.
The reading I have done about these that they are very fussy about the dimensions. The septum's dimensions can make a very large difference in signal.
Again since I haven't made one yet I can't say. But I don't see a reason why it wouldn't work.
Exactly, other than simply as test signal, Outernet is useless to me. (I think the company behind it will soon be history too.)

...
The GRB signal is still being sent. If you keep wondering about that go to here (link) and look at the UTC time stamp as these guys get as close to realtime data over the web as it gets.
That is compelling evidence that my septum feed failed to perform its assigned purpose. :facepalm

Back to the drawing board.....
 
...
On another note my new Novra S300 will be here in a day or less, finally shipped as I had to wait for it to come from Canada.
I hate to be the bearer of bad news, but I am pretty sure that the S300 does not support GSE (Generic stream) mode. And, of course, GRB needs that.

For GSE you need the Novra S400, which has not been released yet.
 
Septum feeds are good for linear too.

The research I have done don't support that, those feeds are RHCP,LHCP. Hmm interesting...


That is compelling evidence that my septum feed failed to perform its assigned purpose.

I am assuming that the septum feed we are discussing here is the square body OK1DFC style?
I want to look farther into those dimensions that were calculated by Lucas's webpage.

I hate to be the bearer of bad news, but I am pretty sure that the S300 does not support GSE (Generic stream) mode.

Unless I'm missing something...
I think when the term (generic) is used in the PUG that covers muti formats of data transmission over DVB-S2. In the case of GRB I'm quite shure it's UDP or IP. If my S300 failed then a few posts back I wouldn't have had signal lock and be able to begin decoding Ethernet packets from the stream.
The DVB packets counter was at zero due to me not having the PID's set to forward. Same happens with NOAAPORT if you don't set the PID's to forward. I know as I created the same condition after I brought the S300 in from the tests with GRB. As soon as the PIDS were entered the DVB packet counter began to grow larger and data is seen at the computer.
I did that post and even tried to counter myself during writing that post to confirm that I was indeed getting valid data. When I was done there is no doubt in my mind that it was decoding the GRB RHCP stream, just not forwarding the data due to the settings above.
The manual and everything I have said it was decoding the DVB-S2 stream outer layer as it should.
As I stated back several pages ago that I am pretty shure that GRB uses the same transmission format that NOAAPORT uses in terms of generic data transport over DVB-S2.
Otherwise please explain.
I was hoping to do one more test with the S300 receiver before the move but due to the bad timing when the company shipped it.. it's now delayed by UPS so... I don't think I will have it before the move unless it arrives today. Otherwise I will have to wait until Dec. to do any more.
 
...
I think when the term (generic) is used in the PUG that covers muti formats of data transmission over DVB-S2. In the case of GRB I'm quite shure it's UDP or IP....
UDP and TCP/IP are internet protocols, and have nothing to do with DVB-S2.

Generic Stream (GSE) is a DVB-S2 protocol. The folks on the Open Satellite group chat room are saying that GRB requires GSE. That's why they are using an Ayecka receiver with beta (unreleased) GSE firmware. The Novra S400 spec sheet is the only one I have seen that mentions GSE. If the Novra S300 happens to work, thats great -- but I will be surprised.
 
Last edited:
C&P today from "@weather1089" on the Open Satellite chat:

"N6BY, Ive had an S300 for quite some time for NOAAPORT. And you are correct, it will not work for GOES16.
I had a long conversation with the NOVRA folks, they are telling me the new S400 MAY work, but didnt promise it yet"
 
"N6BY, Ive had an S300 for quite some time for NOAAPORT. And you are correct, it will not work for GOES16.

N6BY,
You're right. I was thinking the stream was (in terms of generic) MPE not GSE.
That's why the S300 can lock on but can't extract any data due to the GSE protocol.
And it's typical of governments and commercial to use such early advanced protocols like this as price for them is not an issue. 1 grand ahh drop in the bucket, though when talking these earth stations it is.
The silver lining is.. GSE can and will be used in many other applications + since it's the new standard it will most likely become standard on good quality DVB-S2 receivers in the future therefore lowering the cost and becoming available to the general user. Early example is the Novra S400, However.....
The question is how long will that be?

So at least I determined what size of antenna should work here as the S300 has a solid lock on the signal.
Otherwise it will be the waiting game.
Don't got much more to add to this forum so I will just be on the side for now. I'll leave the forum open to anybody that wants to put in their 2 cents.
As well to any updates of the projects.
 
N6BY I have a question for you.
I was looking around tonight after continuing to do more research and found this...

TBS 5927
It supports Multiple Generic Stream, Combined Single Generic, Constant Coding Modulation (CCM).
From all the talking we have been doing, this receiver seems to support the GRB DVB-S2 outer layer format.
So why wouldn't this work?

And the cost is very reasonable.
 
N6BY I have a question for you.
I was looking around tonight after continuing to do more research and found this...

TBS 5927
It supports Multiple Generic Stream, Combined Single Generic, Constant Coding Modulation (CCM).
From all the talking we have been doing, this receiver seems to support the GRB DVB-S2 outer layer format.
So why wouldn't this work?

And the cost is very reasonable.
Hi. While the specs sound good, I really can't confirm if he 5927 will work or not. Open Satellite Project (Lucas Teske) is working with a TBS6903. Due to subtle hardware differences, I don't even know if my TBS6983 will work. So the safest bet would be to get a 6903.

I think Lucas is close to getting the 6903 working. According to OSP, the TBS 6903 can record Generic Stream using the 'TBS Recorder' app. But the 'TBS IP' tool doesn't stream Generic -- very odd. So, he got the source code for TBS Recorder from TBS and is working on making it stream Generic over the net (instead of recording to disk).

They haven't released a Generic streaming beta yet. My guess is that they will wait until GOES-16 comes back online in a few weeks.

...Meanwhile, I am taking the time while GOES-16 is down to try to make a much higher precision version of the septum feed. I think that the measurements of my first attempt were off a bit. I may be placing an order soon with onlinemetals.com to get a precision square tube as a waveguide. I might need a machine shop to accurately cut the septum.
 
N6BY,
Thanks for the advice.
Looking at the TBS6903 and the TBS5927 the only difference is one is PCIe card and one is stand alone according to specs.
Looking at TBS manual it can stream UDP, The CSPP software I want to use uses UDP in the stream mode it runs.
Thought I put that up here since I found that.


I looked at Lucas's calculator and found some of his dimensions to be off by 10 even 20 mm on the septum for 1.2 Ghz (when I last checked it). I don't know what info he is using but what I have that shows the OK1DFC septum feed drawing dimensions is different.
Though his main sizes for the waveguide are correct, waveguide lengths can vary. The septum itself has had many changes depending on who made the feed and the type of feed.
If you can make it out of cardboard/tin foil that would be the way I'd go before you make a big materials purchase. Just like you did with the Quaker oats container (make a prototype).

If you feel adventurous.. I can put up my drawings of the septum feed design.
It's untested so the results may not be as good as it should be.
I haven't had time to get some cheap material together to build the thing, and like your case it's tough to find round tube that size. But if you want to give it a go, by all means be my guest.
 
N6BY,
... Looking at the TBS6903 and the TBS5927 the only difference is one is PCIe card and one is stand alone according to specs.
Looking at TBS manual it can stream UDP, The CSPP software I want to use uses UDP in the stream mode it runs.....
I don't know if Lucas's Open Satellite project will be written to support only PCIe cards, or if it will also support USB boxes? And the other thing I find puzzling is that the CSPP GRB software does not specify a satellite tuner card at all. From what I read, it sounds like so far they have only used canned test data for testing (from files), not a live GRB feed.

I looked at Lucas's calculator and found some of his dimensions to be off by 10 even 20 mm on the septum for 1.2 Ghz (when I last checked it). I don't know what info he is using but what I have that shows the OK1DFC septum feed drawing dimensions is different....
You're right, thanks for noticing that. The hand drawn diagram made by OK1DFC at http://www.ok1dfc.com/eme/Technic/septum/23-13draw.pdf does indeed have significantly different dimensions along the width of the feed, but the dimensions along the length match the calculator.

And to add more confusion, OK1DFC also has a calculator on his website which differs from his own hand drawn diagram. But OK1DFC's own calculator http://www.ok1dfc.com/eme/Technic/septum/calc.xls matches Lucas's Open Satellite calculator.

OK1DFC's hand drawn diagram assumes a feed opening of 0.95 wavelength. But both Lucas's and OK1DFC's online calculators assume an opening of 0.81 wavelength. Not sure which one is best for a prime focus dish with an f/D of 0.4?

It would be great if we had a septum feed expert here at SatelliteGuys to shed some light on the discrepancy. Lacking that, I am inclined to go with the calculators septum dimensions.
 
I figured out why some of the numbers are different on OK1DFC's diagram vs. the calculators. The diagram includes 12.5 mm 'overhangs' on the top and bottom of the septum. The overhangs are outside of the wave guide. They are just there for attachment to the 12.5 mm lips of the wave guide halves. If you subtract out the 12.5 mm on the top and bottom, the dimensions match the calculators. :)
 
And the other thing I find puzzling is that the CSPP GRB software does not specify a satellite tuner card at all.

From what I have determined the software don't care what is processing the DVB-S2 data just as long as it sees the UDP stream on a port in streaming mode. Such as in the TBS5957 manual you can use Astra and stream the UDP data on port 8020, the GRB software is set up to look on that port for the data.

It can process data another way but it requires stripping the transfer layer off and only sending the CCSDS packets to the software. This process is more controlled but also requires more hardware/software preprocessing.
And it still looks for that preprocessed data on a port.

From what I read, it sounds like so far they have only used canned test data for testing (from files), not a live GRB feed.

At the time that version V0.3 of the software was written, that's the only way they could have done a test as the satellite was not deployed at that time. As did everyone making any kind of GRB ingest system.
The latest version V0.4.6 has used the live data that comes from the satellite.

Not sure which one is best for a prime focus dish with an f/D of 0.4?

The match for a dish is done more through the choke ring then the waveguide. Like the chaparral feed, the collar around the waveguide itself helps the f/d matching. And improves as there are rings added inside the main collar like Chaparral's.
That is why I use it with my feeds as seen in the pictures with the feed mounted at the dish.
According to the software tests run and info published a straight feed will under illuminate the dish and or unevenly. This also (the software predicts) makes the circular polarization get out of phase as one moves away from theta. (if I'm explaining that correctly)
 
From what I have determined the software don't care what is processing the DVB-S2 data just as long as it sees the UDP stream on a port in streaming mode. Such as in the TBS5957 manual you can use Astra and stream the UDP data on port 8020, the GRB software is set up to look on that port for the data....
I can confirm from multiple sources that currently there is no TBS software that can create a UDP stream from DVB-S2 generic. The only known working software is TBS Recorder, but it does not create a UDP stream.

Buy the 5957 if you want, but until Lucas Teske or someone else creates generic UDP streaming software, it will be good only for watching TV.

At the time that version V0.3 of the software was written, that's the only way they could have done a test as the satellite was not deployed at that time. As did everyone making any kind of GRB ingest system.
The latest version V0.4.6 has used the live data that comes from the satellite....
According to this on page 20 : http://www.ssec.wisc.edu/meetings/cspp/2017/presentations/day1/7_CSPP_WorskhopV2_goodson.pdf CSPP GRB V0.4.6 is using the Quorum GRB-200 which lists for the princely sum of $17,995? http://www.qcom.com/datasheets/prices.pdf

I'll have to wait for a lower cost alternative. ....Meanwhile, I figured out where I went wrong with my first attempt at a septum feed. I have parts on order from Online Metals for my next attempt.
 
Buy the 5957 if you want, but until Lucas Teske or someone else creates generic UDP streaming software, it will be good only for watching TV.

As you stated before, That is odd it only records the data but don't forward it.
I was just pointing out what I read in the manual. I plan to make no buys right now. As I said, I'm waiting and seeing.

CSPP GRB V0.4.6 is using the Quorum GRB-200 which lists for the princely sum of $17,995?

There are other receivers that are capable of this not just Quorum's. It's just where that they are at ??????
Gov of Canada can pay that. Isn't that something, I don't think there is anything on that list under a grand! :oldno
But, as I stated before.. they can charge that as the industry they work with can pay that as It's not meant for you and me. Though it's nice to see the GEO CSPP software in actual use. :)

When you talked to the guys at OSP and said that they got their first GRB image from the stream.
What size of dish was OSP using there?
I'm curious.

I figured out where I went wrong with my first attempt at a septum feed.

Do keep me informed about that. Glad you found the problem.
 
As you stated before, That is odd it only records the data but don't forward it....
Yes, very disappointed that TBS updated the recording software to support generic stream, but not the IP tool. But at least we know its possible with the right software.

When you talked to the guys at OSP and said that they got their first GRB image from the stream.
What size of dish was OSP using there?
I'm curious....
@weather01089 reported that he is using a 10 foot mesh for GRB. He is at approximately 72 degrees longitude.


...
Do keep me informed about that. Glad you found the problem.
Thanks. Here is a link to some septum feed tolerances and sensitivity testing done by W1GHZ: http://www.w1ghz.org/antbook/conf/Septum_Feeds-Tolerances_and_Sensitivity.pdf It turns out that the septum step dimensions are very forgiving, even for a 5% error. But the waveguide has to be almost perfectly symmetric and of consistent dimensions. Since I made my waveguide from two sections of metal bent by hand, it was far from perfect. And my other mistakes were that the septum did not make sufficient electrical contact with the waveguide, and the probes need to be much thicker than the width of the wire (for proper impedance matching).

Wednesday I should have the parts from onlinemetals.com to build the new septum feed. Until GOES-16 is back in service, I will test it with Outernet.
 
Last edited:
I guess TBS figured generic wasn't going to be used for much at that time. It's still fairly new in how it's being used so hardware/software will have to catch up, and it will.
You know (slightly off topic) I don't why EMWIN/HRIT went using BPSK legacy format when (in my opinion) they could have went to a DVB-S2 standard using MPE protocol. Such as NOAAPORT.
The hardware is available and the format even if it isn't as efficient as it could be. It can transfer more data in the future streams. There is probably a reason but eh, I don't know.

@weather01089 reported that he is using a 10 foot mesh for GRB.

Good, thanks for the info. As I figured I'm good there.

Paul W1GHZ has given me info on request when I had some questions, He is a good guy. My thanks go out to him all the others for the info.
Waveguide is the foundation of the dish feed, If it's erred the the whole thing is erred. There have been many hours put into the testing of different feeds with many results.
My feed was built on some of those results and it makes it a lot easier when those results are known about what to expect.
Though it still seems some trial and error is needed for a final result at times.
Take your time as prettiness don't really count but tolerances do.
When I make a waveguide, I make it on a form or mandrel. It's the shure way I have found to hold everything as it's being soldered and fastened together.
 
I don't why EMWIN/HRIT went using BPSK legacy format when (in my opinion) they could have went to a DVB-S2 standard using MPE protocol.

Answer to my own question is: NOAA didn't have the transponder space. It would have required 2 Mhz bandwidth for it to be any real use.
Though if they could have it may been able to do up to 3 Mbps speeds instead .400 kbps. Oh well.
 
...There have been many hours put into the testing of different feeds with many results.
My feed was built on some of those results and it makes it a lot easier when those results are known about what to expect.
Though it still seems some trial and error is needed for a final result at times....
If my second attempt at a septum feed works, I will be indebted to W1GHZ for discovering which dimensions are critical and which aren't.

Speaking of that, I got my onlinemetals.com parts Wednesday. They ship fast! They even cut the pieces to my requested sizes.

Should have the septum feed ready to test in a week or so. But I will have to put my 10 foot Unimesh back up. (I took it down when I got my Birdview). First thing I plan to measure is the cross polarization isolation on the Outernet signal. If all goes well, one side of the septum feed will get a strong signal and the other side will be about 20-30 dB lower.
 
Top