Welcome to GOFASTMOTORSPORTS.com ... ... ... Green Flag - Green Flag - Go Go Go ... ... Brought to you by Ricks Satellite - Where the Big Dish Rules!

Ricks Satellite Wildfeed and Backhaul Forum
Register Latest Topics
 
 
 


Reply
  Author   Comment   Page 6 of 21     «   Prev   3   4   5   6   7   8   9   Next   »
andyinyakima

Avatar / Picture

Registered:
Posts: 1,520
Reply with quote  #76 
I think there is something in the drivers that have to addressed. I think GSE was in the experimental stage and wasn't of much concern when the drivers were developed; so the drivers were not written with GSE in mind.

TS is actutally more complicated to break down in my estimation then GSE, but in its favor the drivers are built to package everything in 188 byte bales. I'm still trying to figure out where GSE stream FIFOs (buffers) should be placed (in the drivers or the demuxes). Should they be IDed in the drivers or the demuxes???

What I would like to see is way to pick a PID, find out if it's encrypted, if it is then reject it, if not buffer it like youtube videos do and then play it from the buffer. It may be text, audio or video.

I too, have put GSE on the back burner on simmer. Anyhow I won't give up on it. Just too many transponders doing GSE.

__________________
andyinyakima
-----------------------------------
Recs: TBS6983, TBS5925 __ Ant: 90cm on SG6100__OSes: Linux with v4l-updatelee drivers __ RPi2 with v4l-updatelee drivers

Open Book, Open Source, You have to Open it to Know what's in it!
updatelee

Avatar / Picture

Registered:
Posts: 3,108
Reply with quote  #77 
Linux is hard coded to 188 byte packets, you can see where I've changed it so it can use 188 or 131 byte packets. It would need to be changed again for raw. It can be done on some devices, others have a 188 byte packet limit built into the device, those can't be changed.

UDL

__________________
TBS6925/5980, Prof 7301/7500/8000, Genpix Skywalker-1, Skystar 2 Express HD
Hauppauge 950Q/Aero/Aero-m, Kworld 330U/435v3/445v3

I use Linux and support open source projects
Download my opensrc projects at http://updatelee.blogspot.com
andyinyakima

Avatar / Picture

Registered:
Posts: 1,520
Reply with quote  #78 
Quote:
Originally Posted by updatelee
Linux is hard coded to 188 byte packets, you can see where I've changed it so it can use 188 or 131 byte packets. It would need to be changed again for raw. It can be done on some devices, others have a 188 byte packet limit built into the device, those can't be changed. UDL


UDL,

Is 188 byte packet limit a hardware limitation. Receivers with 16APSK and 32APSK shouldn't fall under this limitation should they?

I have read somewhere[confused] that the stv0903 devices will not support short frames so that eliminates them from GSE for me. I do not have one of those devices, so I can't verify that.

Another thing for me is signal strength and quality especially on 16APSK  I will break Lock. On 32APSK I am lucky to get Lock! lol

There are two transponders on 123W that I experiment with 12142 V 4172 and 12171 V 4172. They both show up in Blind Scan.

__________________
andyinyakima
-----------------------------------
Recs: TBS6983, TBS5925 __ Ant: 90cm on SG6100__OSes: Linux with v4l-updatelee drivers __ RPi2 with v4l-updatelee drivers

Open Book, Open Source, You have to Open it to Know what's in it!
midwestmac

Registered:
Posts: 2,275
Reply with quote  #79 
Hey Guys, in windows what TBS has done to the driver it seems to work so so, not perfect with these switching modulations. Maybe this all that can be done with the modcod thing?
 for example I can lock a GS-MIS-ACM transponder at a signal level 18db's thats sitting at DVBs2-qpsk then switches to DVBs2-8psk and back in forth like that maybe a 16apsk will get tossed in there for a second or two, but yet I might still get errors in my recording.
 
 Anyways
Right now with the apps we have and what makes viewing Mpeg-2 hard is the way TS is sent inside of a BBframe along with the "GSE header" to mark its destination. The GSE header could have a fragment ID with no label, or it might have a fragment ID with 3,6 byte label to mark its reciever destination.
From Mips suggestion is to record the whole stream, then we can sort out all the extra data that doesn't fall under the 188bytes 
The other day I tried to manually sort through one recording with a hexeditor and I got up to about 50 different GSE fragment ID's (more study and learning to do)
Here's my theory and from what I've read,
Some BBframes with a GSE header have nothing really inside of them I think because the transmission is at "idle speed" or has switched to DVBs2-qpsk. 
It might take a few minutes before the transmission of a BBframe with a TS packet is sent.
But when it switches to a DVBs2-8psk ,16apsk or a 32apsk then data starts again.
Some of the transmissions are sent to all receivers listening, some transmissions are for a particular receiver
 
I think when we see a small glimpse of a video its a BBframe with several 188 byte ts packets being sent. Then the transmission might go back to DVBs2-qpsk until that particular receiver with its own fragment ID and/or 3,6 byte label wants some more at s2-8psk,16apsk or 32apsk
And who knows what a video could be? Might be a youtube video, but 2 years ago I did catch a glimpse of a live college game.
 
 
Here's a screen shot of a BBframe header and a GSE header highlighted in blue with a the TS packet highlighted in green.
Using a hex editor these TS packets in this particular BBframe all fall right in place at 188 bytes, although!! with the hexeditor I found a few 188bytes that overlap into the next BBframe which doesn't make sense? Unless the transmission needs to be resent again, corrected with the 8 byte CRC32?, or I just have a poor recording. Not sure?
 
   
 

Attached Images
Click image for larger version - Name: GSE2014-09-16_0903.png, Views: 59, Size: 121.54 KB 

__________________
Azbox Ultra, Pansat 2500, Prof7301,Tbs 6925,5980, Genpix 8psk card, Dektec 2137c, Hauppauge 950q

updatelee

Avatar / Picture

Registered:
Posts: 3,108
Reply with quote  #80 
Quote:
Originally Posted by andyinyakima
Quote:
Originally Posted by updatelee
Linux is hard coded to 188 byte packets, you can see where I've changed it so it can use 188 or 131 byte packets. It would need to be changed again for raw. It can be done on some devices, others have a 188 byte packet limit built into the device, those can't be changed. UDL


UDL,

Is 188 byte packet limit a hardware limitation. Receivers with 16APSK and 32APSK shouldn't fall under this limitation should they?

I have read somewhere[confused] that the stv0903 devices will not support short frames so that eliminates them from GSE for me. I do not have one of those devices, so I can't verify that.

Another thing for me is signal strength and quality especially on 16APSK  I will break Lock. On 32APSK I am lucky to get Lock! lol

There are two transponders on 123W that I experiment with 12142 V 4172 and 12171 V 4172. They both show up in Blind Scan.


Some hardware is hard coded for 188 byte packets (the interface IC) some sends it as is then Linux buggers it up because its hard coded to 188 bytes. 

I did some testing before with DSS's 131 byte packets, but cant remember the outcome of what devices works and what ones didnt lol.

UDL

__________________
TBS6925/5980, Prof 7301/7500/8000, Genpix Skywalker-1, Skystar 2 Express HD
Hauppauge 950Q/Aero/Aero-m, Kworld 330U/435v3/445v3

I use Linux and support open source projects
Download my opensrc projects at http://updatelee.blogspot.com
midwestmac

Registered:
Posts: 2,275
Reply with quote  #81 
Andy,  I have your GSEsort app to work and was wondering. What do you think about if it could sort by protcol type
  If an array could read the 16 and 17th byte and group these GSE headers together by the protocol type 
 
Then after they are sorted and grouped by protocol type, I could look at them again with a hex editor (looking for TS packets) to see the significance of where TS packets are, there in a file I have recorded. If that makes sense. And maybe try and piece one together that way.

LINE#          BBFRAME Header                    GSE HEADER   (in red-protocol type)  
24448  42 00 00 00 05 98 2b 00 00 9b     c0 15 00 02 00 80 99 08 53 6f cd 01 58
33623  42 00 00 00 37 48 38 00 00 a9     c5 59 00 02 00 ff fd c1 00 00 00 01 59

What do you think? Would that be hard to add in, or is it a dumb idea?



__________________
Azbox Ultra, Pansat 2500, Prof7301,Tbs 6925,5980, Genpix 8psk card, Dektec 2137c, Hauppauge 950q
andyinyakima

Avatar / Picture

Registered:
Posts: 1,520
Reply with quote  #82 
have you guys looked at the wireshark sample at:

http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=dvb-s2_bb_example.pcap

it shows 08 at the start of every bbframe

midwestmac's message before last had a pix.

The pic showed 47 08 each 188 block, my worry is that the frame may have been truncated.

The wireshark example shows variable lengths I think based on modcod. So if you get a chance take a look and let me know your thoughts.

UDL you mentioned the interfaced chip is sometimes hard coded for 188 bytes in my case that would be the Cypress USB chip correct?? I have the spec sheet on that somewhere, better check to see if I'm banging a wall and see if there might be a work around. Maybe it's possible to push everything through and just strip the syncbyte but then again I worry that some of the frame maybe truncated.

Any how I'm still looking.

__________________
andyinyakima
-----------------------------------
Recs: TBS6983, TBS5925 __ Ant: 90cm on SG6100__OSes: Linux with v4l-updatelee drivers __ RPi2 with v4l-updatelee drivers

Open Book, Open Source, You have to Open it to Know what's in it!
updatelee

Avatar / Picture

Registered:
Posts: 3,108
Reply with quote  #83 
Tune a DSS tp, they are 131 bytes, if you see the 0x47 at 188 byte interval then it's the interface ic messing it up.

UDL

__________________
TBS6925/5980, Prof 7301/7500/8000, Genpix Skywalker-1, Skystar 2 Express HD
Hauppauge 950Q/Aero/Aero-m, Kworld 330U/435v3/445v3

I use Linux and support open source projects
Download my opensrc projects at http://updatelee.blogspot.com
mips

Registered:
Posts: 529
Reply with quote  #84 
Quote:
Originally Posted by andyinyakima

The pic showed 47 08 each 188 block, my worry is that the frame may have been truncated.


midwestmac's picture suggests those are transport packets (within a GSE packet). They start with 0x47, are spaced every 188 bytes, and the continuity counter increments as expected. The PID is 0x0800.

The 0x0800 value in the wireshark sample does not refer to a PID. That's the beginning of the Ethernet frame, not the DVB-S2 BB frame. The BB frame starts with 0x6000.

Quote:
Originally Posted by andyinyakima

The wireshark example shows variable lengths I think based on modcod. So if you get a chance take a look and let me know your thoughts.


The wireshark sample appears to be using a format different from midwestmac's recordings. I see "dumpcap" mentioned near the beginning and end of the sample, so it doesn't look like a raw recording. I guess that's why it uses a .pcap extension. The sample is useful to get a general understanding of BB frames and GSE packets, but it contains extra layers that I don't see in raw recordings.

mips

Registered:
Posts: 529
Reply with quote  #85 
Quote:
Originally Posted by midwestmac

LINE#          BBFRAME Header                    GSE HEADER   (in red-protocol type)  
24448  42 00 00 00 05 98 2b 00 00 9b     c0 15 00 02 00 80 99 08 53 6f cd 01 58
33623  42 00 00 00 37 48 38 00 00 a9     c5 59 00 02 00 ff fd c1 00 00 00 01 59

The protocol type is at the wrong location. It should be:
24448  42 00 00 00 05 98 2b 00 00 9b     c0 15 00 02 00 80 99 08 53 6f cd 01 58
33623  42 00 00 00 37 48 38 00 00 a9     c5 59 00 02 00 ff fd c1 00 00 00 01 59

0x0002 is the protocol type for TS concatenation.

andyinyakima

Avatar / Picture

Registered:
Posts: 1,520
Reply with quote  #86 
mips,

My main concern at present is to see why everything is getting treated like a transport stream with a sync byte 0x47. What ever is causing this is also causing the packets to be truncated to a 188 byte packet size and there by loosing information.

I get the impression that UDL is of the feeling that it might be a hardware issue. If that is in fact the case, then a work around may need to be used; although the work around will be a lot slower and  still may end up with error filled info.

Then again maybe the 0x47 sync byte is just being added to the stream and no truncation is being performed (which I find hard to believe). Anybody with  thoughts on that. I can't seem to find any 188 byte packets that look like they should be (batch a) and (batch b) and back to back. I will try find an example of what I mean.

__________________
andyinyakima
-----------------------------------
Recs: TBS6983, TBS5925 __ Ant: 90cm on SG6100__OSes: Linux with v4l-updatelee drivers __ RPi2 with v4l-updatelee drivers

Open Book, Open Source, You have to Open it to Know what's in it!
midwestmac

Registered:
Posts: 2,275
Reply with quote  #87 
Thanks Mips and Thanks to Rick for letting us share what we find here.

Mips the last one I sent was an exceptional on I think its up 24/7 mostly.
I guess it has a program guide behind it?
I was wondering what recordings are useful?  So I uploaded one more thats different but its what we see alot of around here with the pids 256 and 257 showing up alot

Thanks

__________________
Azbox Ultra, Pansat 2500, Prof7301,Tbs 6925,5980, Genpix 8psk card, Dektec 2137c, Hauppauge 950q
andyinyakima

Avatar / Picture

Registered:
Posts: 1,520
Reply with quote  #88 
midwestmac

Have you tried 12082 v 1842 on 123 W? 

Lot of text but mine is still getting truncated a bit.

__________________
andyinyakima
-----------------------------------
Recs: TBS6983, TBS5925 __ Ant: 90cm on SG6100__OSes: Linux with v4l-updatelee drivers __ RPi2 with v4l-updatelee drivers

Open Book, Open Source, You have to Open it to Know what's in it!
updatelee

Avatar / Picture

Registered:
Posts: 3,108
Reply with quote  #89 
Quote:
Originally Posted by andyinyakima
mips,

My main concern at present is to see why everything is getting treated like a transport stream with a sync byte 0x47. What ever is causing this is also causing the packets to be truncated to a 188 byte packet size and there by loosing information.

I get the impression that UDL is of the feeling that it might be a hardware issue. If that is in fact the case, then a work around may need to be used; although the work around will be a lot slower and  still may end up with error filled info.

Then again maybe the 0x47 sync byte is just being added to the stream and no truncation is being performed (which I find hard to believe). Anybody with  thoughts on that. I can't seem to find any 188 byte packets that look like they should be (batch a) and (batch b) and back to back. I will try find an example of what I mean.


mainline Linux puts a 0x47 every 188 bytes, never fail. My kernel puts one every 188 bytes unless its DSS, then puts them every 131 bytes.

GSE would fall under the 188byte rule. Linux WILL put that byte every 188 bytes every time. Now my comment for tuning DSS was just to see if your hardware supports other packet sizes. Ie if it only supports 188 byte packets, then you'll see a 0x47 every 131 bytes AND 188 bytes. it'll be corrupt. If you only see them every 131 bytes, then your good to go to modify the linux kernel to support raw and not enter any sync bytes at all.

Unless the GSE your tuning supports 188 byte packets, I havent read up much, but I believe thats unlikely, so Linux as is will completely corrupt GSE as is.

UDL


__________________
TBS6925/5980, Prof 7301/7500/8000, Genpix Skywalker-1, Skystar 2 Express HD
Hauppauge 950Q/Aero/Aero-m, Kworld 330U/435v3/445v3

I use Linux and support open source projects
Download my opensrc projects at http://updatelee.blogspot.com
mips

Registered:
Posts: 529
Reply with quote  #90 
Quote:
Originally Posted by andyinyakima
mips,

My main concern at present is to see why everything is getting treated like a transport stream with a sync byte 0x47. What ever is causing this is also causing the packets to be truncated to a 188 byte packet size and there by loosing information.


Ah sorry, I didn't realize you were looking at that issue. I might have missed some posts.

FWIW, midwestmac's recordings don't have that problem. He might be using Windows though.

Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.

Fellow Members, your posts are welcome here! Do not worry about posting everything perfect. Different receivers and LNB's will give you different Frequencies and Symbol Rates. Some set top boxes, PCI cards and USB receivers, Do Not Require all of the same information that others may need. It is not Required to post everything that others may need to tune in a feed. It is just most important to share the find. We can always adjust the Frequency and Symbol Rates and try the various Modulations and FEC's on our own receivers until we get a lock and then give a polite reply with what works for your receiver, as that information might help others as well. We all appreciate the efforts and energy of the Posters!

Thank You for Visiting GOFASTMOTORSPORTS.com - Keep Your Eyes on the Sky and the Track!