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 4 of 21      Prev   1   2   3   4   5   6   7   Next   »
mips

Registered:
Posts: 529
Reply with quote  #46 
Quote:
Originally Posted by midwestmac
Oh by the way, Back to the BBheader in my recordings I have a "42 00 00 00" and a "42 00 02 00". Have to see what mips thinks the "42 00 02 00" I get a DFL that doesn't line up right so I don't know? I'll have to look at it more.
But the 42 00 00 00 the DFL lines up fine so far.


midwestmac, I'm just reposting my reply for everyone's benefit.

I also found that the 42 00 02 00 sequences tend to be flaky, they might not be real BB headers, although I'm still not convinced. Their SYNC value doesn't usually line up with previous/next SYNC values in the stream. I'll probably analyze those sequences further down the road. Perhaps a GSE stream within a GSE stream?
midwestmac

Registered:
Posts: 2,275
Reply with quote  #47 
Thanks mips I'll keeep checking the DFL and CRC with your tool. And I'm trying to find a ACM/VCM transport stream that might have something useful they are all over the place but most will say AOL with tsreader (not sure what to look for yet?) and also see what a packetized stream looks like, I found one once.
If i can get a good lock that fox news signal again it was switching a little but played with vlc until they changed something but it was a SIS stream (maybe easier)? I have a new ku scaler to put on my dish and some tuning to do sometime.


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

Avatar / Picture

Registered:
Posts: 5,644
Reply with quote  #48 
With one of the files I recorded, I wrote a short VB program that:
looked for the first 50 occurrences of  "42 00 00 00"
printed the byte location, the DFL, and the next calculated byte location.
It seemed to work perfectly for the first 50, ie :

42000000 found at  370   DFL=  1319   Next 42000000 at  1699
42000000 found at  1699   DFL=  1319   Next 42000000 at  3028
42000000 found at  3028   DFL=  434   Next 42000000 at  3472
42000000 found at  3472   DFL=  16   Next 42000000 at  3498
42000000 found at  3498   DFL=  16   Next 42000000 at  3524
42000000 found at  3524   DFL=  16   Next 42000000 at  3550
42000000 found at  3550   DFL=  16   Next 42000000 at  3576
42000000 found at  3576   DFL=  16   Next 42000000 at  3602
42000000 found at  3602   DFL=  16   Next 42000000 at  3628
42000000 found at  3628   DFL=  16   Next 42000000 at  3654
42000000 found at  3654   DFL=  16   Next 42000000 at  3680
42000000 found at  3680   DFL=  1140   Next 42000000 at  4830
42000000 found at  4830   DFL=  16   Next 42000000 at  4856
42000000 found at  4856   DFL=  16   Next 42000000 at  4882
42000000 found at  4882   DFL=  16   Next 42000000 at  4908
42000000 found at  4908   DFL=  16   Next 42000000 at  4934
42000000 found at  4934   DFL=  16   Next 42000000 at  4960
42000000 found at  4960   DFL=  16   Next 42000000 at  4986
42000000 found at  4986   DFL=  16   Next 42000000 at  5012
42000000 found at  5012   DFL=  16   Next 42000000 at  5038
42000000 found at  5038   DFL=  1289   Next 42000000 at  6337
42000000 found at  6337   DFL=  16   Next 42000000 at  6363
42000000 found at  6363   DFL=  16   Next 42000000 at  6389
42000000 found at  6389   DFL=  16   Next 42000000 at  6415
42000000 found at  6415   DFL=  16   Next 42000000 at  6441
42000000 found at  6441   DFL=  16   Next 42000000 at  6467
42000000 found at  6467   DFL=  16   Next 42000000 at  6493
42000000 found at  6493   DFL=  16   Next 42000000 at  6519
42000000 found at  6519   DFL=  16   Next 42000000 at  6545
42000000 found at  6545   DFL=  16   Next 42000000 at  6571
42000000 found at  6571   DFL=  1332   Next 42000000 at  7913
42000000 found at  7913   DFL=  1319   Next 42000000 at  9242
42000000 found at  9242   DFL=  1319   Next 42000000 at  10571
42000000 found at  10571   DFL=  1319   Next 42000000 at  11900
42000000 found at  11900   DFL=  1319   Next 42000000 at  13229
42000000 found at  13229   DFL=  594   Next 42000000 at  13833
42000000 found at  13833   DFL=  1319   Next 42000000 at  15162
42000000 found at  15162   DFL=  1319   Next 42000000 at  16491
42000000 found at  16491   DFL=  1319   Next 42000000 at  17820
42000000 found at  17820   DFL=  648   Next 42000000 at  18478
42000000 found at  18478   DFL=  16   Next 42000000 at  18504
42000000 found at  18504   DFL=  16   Next 42000000 at  18530
42000000 found at  18530   DFL=  16   Next 42000000 at  18556
42000000 found at  18556   DFL=  16   Next 42000000 at  18582
42000000 found at  18582   DFL=  16   Next 42000000 at  18608
42000000 found at  18608   DFL=  16   Next 42000000 at  18634
42000000 found at  18634   DFL=  16   Next 42000000 at  18660
42000000 found at  18660   DFL=  16   Next 42000000 at  18686
42000000 found at  18686   DFL=  16   Next 42000000 at  18712
42000000 found at  18712   DFL=  1231   Next 42000000 at  19953
42000000 found at  19953   DFL=  16   Next 42000000 at  19979



Also, I told it to go to the first 5000 occurrences and stop if the next byte number didn't correspond, and it didn't find an error.



 
mips

Registered:
Posts: 529
Reply with quote  #49 
Quote:
Originally Posted by midwestmac
And I'm trying to find a ACM/VCM transport stream that might have something useful they are all over the place but most will say AOL with tsreader (not sure what to look for yet?) and also see what a packetized stream looks like, I found one once.
If i can get a good lock that fox news signal again it was switching a little but played with vlc until they changed something but it was a SIS stream (maybe easier)? I have a new ku scaler to put on my dish and some tuning to do sometime.


I took a look at the two files you uploaded today and unfortunately they have the same two problems I mentioned in an earlier post i.e. missing data from the stream causing fake BB headers to be reported (with discontinuous SYNC values) and the CRC of fake headers is being recomputed/overwritten, making them appear valid. I'd say the settings you toggled didn't have any meaningful effect.

Could the missing data be the result of an intermittent loss of signal lock? Just considering alternative explanations...

There are a lot of possible combinations for the MATYPE bits. Each one may provide further insight into the ongoing problem and will have to be tested eventually. If you can record an SIS stream, that would be useful because I only have MIS recordings so far.

mips

Registered:
Posts: 529
Reply with quote  #50 
Quote:
Originally Posted by wejones

Also, I told it to go to the first 5000 occurrences and stop if the next byte number didn't correspond, and it didn't find an error.

That's very encouraging. Let it go to 50000 or 100k occurrences if you can. Even better, process the whole recording.

In one of midwestmac's recordings, the first error occurs around the 29000th occurrence. I don't know how long his recording was in seconds, but it was in the 300 to 400 MB in size.

wejones

Avatar / Picture

Registered:
Posts: 5,644
Reply with quote  #51 
I'll try that, probably tomorrow.  I'll have to remove the printing steps, as that really slows it down.  VB is pretty slow to begin with, but when you have it print to windows, it really goes slow.  My two recordings are 300 and 400 MB. 

I was a bit confused relative to when I made the two recordings.  I was basically recording the entire signal,  and it would zip along, but then seemingly slow down to a crawl, then speed up again, as if it might be ignoring null packets or something.  Seems like if it's slowing down and ignoring packets, that it can't be recording the entire stream.  
wejones

Avatar / Picture

Registered:
Posts: 5,644
Reply with quote  #52 
First of all, I uploaded 2 files to a web page.
http://www.eskerridge.com/bj/sat/stream-demo.zip
and
http://www.eskerridge.com/bj/sat/stream-crazy.zip

Note.... these two files are NOT zipped.  I changed the .ts extension to zip to allow them to be downloaded from my (and probably other) browsers.  You can change it to .ts or .bin or just leave it as it is. 


 
Quote:
Originally Posted by mips
Quote:
Originally Posted by wejones

Also, I told it to go to the first 5000 occurrences and stop if the next byte number didn't correspond, and it didn't find an error.

That's very encouraging. Let it go to 50000 or 100k occurrences if you can. Even better, process the whole recording.

In one of midwestmac's recordings, the first error occurs around the 29000th occurrence. I don't know how long his recording was in seconds, but it was in the 300 to 400 MB in size.
  


Well, I did allow it to go further, and as you suspected, it did run into a problem, out around 15,000 occurrences. 

Everything went well until 6F4123.  The sequence there predicted that the next occurrence would be at 6F4569, however it stopped at 6F4382, where there was a sequence of 42000000 that had 0000 for what should be the DFL.  Then I looked out at 6F4569 where there should have been an occurrence. There was an occurrence there, however it was at 6F4568 instead of 6F4569, ie it seems like one byte is missing for some reason????
 
Quote:

         Previous    i= 6F4123  7291171  21e0=1084*8

006f411c  00 00 f2 14 03 57 42 00  00 00 21 e0 a6 00 00 46  |.....WB...!....F|
006f412c  c0 c7 00 02 00 80 12 c0  00 25 f8 01 c2 45 00 00  |.........%...E..|
006f413c  ba 52 28 00 00 fb 2f 1d  42 ac 1e ff 0a ac 1e f8  |.R(.../.B.......|
006f414c  62 20 00 08 00 00 00 01  94 45 00 00 9e 1f fd 40  |b .......E.....@|
006f415c  00 7d 06 2a 28 ac 19 ba  9b ac 10 a0 6f 0f b6 f0  |.}.*(.......o...|
006f416c  92 0e 67 74 0a c9 67 34  93 50 18 07 3b 37 9e 00  |..gt..g4.P..;7..|


         stopped at   i= 6F4382  7291778

006f4374  e5 5f 67 3b 8d c3 b0 d1  50 18 00 ff 42 42 00 00  |._g;....P...BB..|
006f4384  00 00 00 70 fe 53 4d 42  40 00 01 00 05 00 00 80  |...p.SMB@.......|
006f4394  0b 00 01 00 01 00 00 00  00 00 00 00 05 00 00 00  |................|
006f43a4  00 00 00 00 ff fe 00 00  01 00 00 00 81 08 00 ec  |................|
006f43b4  1b 34 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.4..............|


         calculated  i = 6F4569  7292265

006f4558  07 ea 06 10 5c b5 aa 01  ac 44 8b 02 33 94 e2 fd  |....\....D..3...|
006f4568  42 00 00 00 00 80 00 00  00 f7 e0 0c 00 06 00 00  |B...............|
006f4578  00 00 00 00 00 00 f2 14  03 57 42 00 00 00 00 80  |.........WB.....|
006f4588  00 00 00 f7 e0 0c 00 06  00 00 00 00 00 00 00 00  |................|
006f4598  f2 14 03 57 42 00 00 00  00 80 00 00 00 f7 e0 0c  |...WB...........|
006f45a8  00 06 00 00 00 00 00 00  00 00 f2 14 03 57 42 00  |.............WB.|
006f45b8  00 00 00 80 00 00 00 f7  e0 0c 00 06 00 00 00 00  |................|
006f45c8  00 00 00 00 f2 14 03 57  42 00 00 00 00 80 00 00  |.......WB.......|
006f45d8  00 f7 e0 0c 00 06 00 00  00 00 00 00 00 00 f2 14  |................|
006f45e8  03 57 42 00 00 00 00 80  00 00 00 f7 e0 0c 00 06  |.WB.............|
006f45f8  00 00 00 00 00 00 00 00  f2 14 03 57 42 00 00 00  |...........WB...|
006f4608  00 80 00 00 00 f7 e0 0c  00 06 00 00 00 00 00 00  |................|
006f4618  00 00 f2 14 03 57 42 00  00 00 00 80 00 00 00 f7  |.....WB.........|
006f4628  e0 0c 00 06 00 00 00 00  00 00 00 00 f2 14 03 57  |...............W|
006f4638  42 00 00 00 00 80 00 00  00 f7 e0 0c 00 06 00 00  |B...............|
006f4648  00 00 00 00 00 00 f2 14  03 57 42 00 00 00 00 80  |.........WB.....|
006f4658  00 00 00 f7 e0 0c 00 06  00 00 00 00 00 00 00 00  |................|
006f4668  f2 14 03 57 42 00 00 00  00 80 00 00 00 f7 e0 0c  |...WB...........|
006f4678  00 06 00 00 00 00 00 00  00 00 f2 14 03 57 42 00  |.............WB.|
006f4688  00 00 00 80 00 00 00 f7  e0 0c 00 06 00 00 00 00  |................|
006f4698  00 00 00 00 f2 14 03 57  42 00 00 00 00 80 00 00  |.......WB.......|
006f46a8  00 f7 e0 0c 00 06 00 00  00 00 00 00 00 00 f2 14  |................|
006f46b8  03 57 42 00 00 00 00 80  00 00 00 f7 e0 0c 00 06  |.WB.............|
006f46c8  00 00 00 00 00 00 00 00  f2 14 03 57 42 00 00 00  |...........WB...|
006f46d8  00 80 00 00 00 f7 e0 0c  00 06 00 00 00 00 00 00  |................|
006f46e8  00 00 f2 14 03 57 42 00  00 00 00 80 00 00 00 f7  |.....WB.........|
006f46f8  e0 0c 00 06 00 00 00 00  00 00 00 00 f2 14 03 57  |...............W|
006f4708  42 00 00 00 29 30 a7 00  00 6c c4 fd 00 02 00 80  |B...)0...l......|
006f4718  13 c0 00 1b 02 01 c2 45  40 04 f0 e7 fa 00 00 fb  |.......E@.......|
mips

Registered:
Posts: 529
Reply with quote  #53 
Quote:
Originally Posted by wejones

Everything went well until 6F4123.  The sequence there predicted that the next occurrence would be at 6F4569, however it stopped at 6F4382, where there was a sequence of 42000000 that had 0000 for what should be the DFL.  Then I looked out at 6F4569 where there should have been an occurrence. There was an occurrence there, however it was at 6F4568 instead of 6F4569, ie it seems like one byte is missing for some reason????

Thanks for the files.

You didn't specify which file, but the closest match I could find to 6F4123 was in stream-demo. I don't have 6F4123 but have 6F4122 (7291170 in decimal). There's nothing unusual there (no missing byte). Looking more carefully at what you posted, it looks like there's a discrepancy between the value i (6F4123) and the actual dump right below (which shows the BB header at offset 6F4122). It's off by 1. Perhaps a VB index convention issue?

Unfortunately, I found invalid CRCs in both files, so the recordings are corrupted.

In stream-demo file (happens on the 376314th occurrence):
BBF @ 163503213   MATYPE=$4200 [GS-C  MIS ACM ISSYI=0 GLT=0 RO=2 ISI=$00] UPL=$0000 DFL=$2530 SYNC=$92 SYNCD=$0000 CRC1=$8B
BBF @ 163504413   MATYPE=$4200 [GS-C  MIS ACM ISSYI=0 GLT=0 RO=2 ISI=$00] UPL=$0000 DFL=$2938 SYNC=$93 SYNCD=$0000 CRC1=$63
BBF @ 163505742   MATYPE=$4200 [GS-C  MIS ACM ISSYI=0 GLT=0 RO=2 ISI=$00] UPL=$0000 DFL=$2920 SYNC=$94 SYNCD=$0000 CRC1=$B9
BBF @ 163507068   MATYPE=$A98D [GS-HE SIS ACM ISSYI=1 GLT=0 RO=1 ISI=$8D] UPL=$1804 DFL=$5DA2 SYNC=$8A SYNCD=$2BC3 CRC0=$17 (invalid CRC here)
BBF @ 163510074   MATYPE=$3E06 [GS-P  SIS CCM ISSYI=1 GLT=1 RO=2 ISI=$06] UPL=$0337 DFL=$AC13 SYNC=$5F SYNCD=$CEAC CRC0=$10
BBF @ 163515590   MATYPE=$15E5 [GS-P  MIS CCM ISSYI=0 GLT=1 RO=1 ISI=$E5] UPL=$95C7 DFL=$A17A SYNC=$B1 SYNCD=$656D CRC0=$16

In stream-crazy file (happens on the 6th occurrence):
BBF @ 3320        MATYPE=$4200 [GS-C  MIS ACM ISSYI=0 GLT=0 RO=2 ISI=$00] UPL=$0000 DFL=$1910 SYNC=$A0 SYNCD=$0000 CRC1=$36
BBF @ 4132        MATYPE=$4200 [GS-C  MIS ACM ISSYI=0 GLT=0 RO=2 ISI=$00] UPL=$0000 DFL=$2D70 SYNC=$A1 SYNCD=$0000 CRC1=$AC
BBF @ 5596        MATYPE=$4200 [GS-C  MIS ACM ISSYI=0 GLT=0 RO=2 ISI=$00] UPL=$0000 DFL=$2938 SYNC=$A2 SYNCD=$0000 CRC1=$CB
BBF @ 6925        MATYPE=$4540 [GS-C  MIS ACM ISSYI=0 GLT=1 RO=1 ISI=$40] UPL=$012C DFL=$515C SYNC=$40 SYNCD=$005B CRC0=$06 (invalid CRC here)
BBF @ 9538        MATYPE=$5100 [GS-C  MIS CCM ISSYI=0 GLT=0 RO=1 ISI=$00] UPL=$0200 DFL=$8043 SYNC=$C0 SYNCD=$0017 CRC0=$BE
BBF @ 13652       MATYPE=$EB76 [TS    SIS ACM ISSYI=1 NPD=0 RO=3 ISI=$76] UPL=$7DF8 DFL=$5F57 SYNC=$38 SYNCD=$1023 CRC0=$E9

midwestmac

Registered:
Posts: 2,275
Reply with quote  #54 
Glad you found one of these Wejones, you could try the TbsTSrecorder and see what happens?
Today I found another transponder at AMC 6 11976 H 4149 its strong I have it at 18db's.
But its another MIS stream I was actually able to look at it with Transedit and there was video on it of course the video is broken up.
Anyways, with this signal using the TBSrecorder everything looks all right except this.
Were the sync goes in order until the "00" I think this is bad? 64,65,66,00,00,00,67,00,00,00,00,68

Mips How does this look are these fake BBheaders with the SYNC "00"? And is it hard to calculate the crc or how can I do it?  Thanks Mips
Note:I edited the log here to get this to display. Also Line BBF @ 54558 does line up w/ line BBF @ 55649

BBF @ 53053       MATYPE=$4200  DFL=$2938 SYNC=$64 SYNCD=$0000 CRC1=$C7 
BBF @ 54382       MATYPE=$4200  DFL=$0530 SYNC=$65 SYNCD=$0000 CRC1=$3C 
BBF @ 54558       MATYPE=$4200  DFL=$21C8 SYNC=$66 SYNCD=$0000 CRC1=$34 
BBF @ 55649       MATYPE=$4200  DFL=$0080 SYNC=$00 SYNCD=$0000 CRC1=$F7 
BBF @ 55675       MATYPE=$4200  DFL=$0080 SYNC=$00 SYNCD=$0000 CRC1=$F7 
BBF @ 55701       MATYPE=$4200  DFL=$0080 SYNC=$00 SYNCD=$0000 CRC1=$F7 
BBF @ 55727       MATYPE=$4200  DFL=$1FF0 SYNC=$67 SYNCD=$0000 CRC1=$B2 
BBF @ 56759       MATYPE=$4200  DFL=$0080 SYNC=$00 SYNCD=$0000 CRC1=$F7 
BBF @ 56785       MATYPE=$4200  DFL=$0080 SYNC=$00 SYNCD=$0000 CRC1=$F7 
BBF @ 56811       MATYPE=$4200  DFL=$0080 SYNC=$00 SYNCD=$0000 CRC1=$F7 
BBF @ 56837       MATYPE=$4200  DFL=$0080 SYNC=$00 SYNCD=$0000 CRC1=$F7 
BBF @ 56863       MATYPE=$4200  DFL=$2938 SYNC=$68 SYNCD=$0000 CRC1=$52 
BBF @ 58192       MATYPE=$4200  DFL=$2938 SYNC=$69 SYNCD=$0000 CRC1=$D1 
 

edited: labled w/ colors

amc6datahex.png amc6logcap.png 


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

Avatar / Picture

Registered:
Posts: 5,644
Reply with quote  #55 
Quote:
Originally Posted by mips
....
Thanks for the files.

You didn't specify which file, but the closest match I could find to 6F4123 was in stream-demo. I don't have 6F4123 but have 6F4122 (7291170 in decimal). There's nothing unusual there (no missing byte). Looking more carefully at what you posted, it looks like there's a discrepancy between the value i (6F4123) and the actual dump right below (which shows the BB header at offset 6F4122). It's off by 1. Perhaps a VB index convention issue?

Unfortunately, I found invalid CRCs in both files, so the recordings are corrupted.
.......



Re the 6F4123  vs 6F4122 , no not a VB issue so much as a question of whether you start the file a zero or one.  I was using a couple binary editors that assumed the first byte was zero, but in my program, I was assuming the first byte was one. I did the calculation of where the next byte should be based on the file starting with "1", but I checked to see if it was really there using linux hexdump, which assumes the first byte is "0".   VB will do it either way, I think I just chose the way that wasn't consistent with the programs I was using to display the bytes.  Ie programming error on my part. 

I think the occurrence at 6F4122 {or 3}  just happened to have an occurrence of 42000000 in the actual data, which my program took to be an error.  Perhaps each time I found an occurrence, I should have just skipped to the calculated next occurrence instead of searching for it.  Would have been a lot faster too.  
 
Re the re the invalid CRCs you find in this and other recordings, I'm wondering if perhaps this might be expected.  I can't remember which document, but I seem to remember reading something in one of the documents posted in this thread, to the effect that particularly with ACM transmissions, that it was likely to have fragmented data when modes switched. I think the document was trying to explain how that would be handled at the receiver, but I didn't understand what I was reading.

  I don't suppose that there is any way to tell from this data when there was a switch in modes?  Not likely I guess, but if there was, it would be interesting to see if perhaps the errors showed up when it switched to 32APSK or something like that?



mips

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

Anyways, with this signal using the TBSrecorder everything looks all right except this.
Were the sync goes in order until the "00" I think this is bad? 64,65,66,00,00,00,67,00,00,00,00,68

Mips How does this look are these fake BBheaders with the SYNC "00"? And is it hard to calculate the crc or how can I do it?  Thanks Mips

I noticed the same thing in wejones' recordings. This is purely a guess at this point but I'd be tempted to think of those DFL=$80 with SYNC=00 as dummy BB headers (similar to the null PID in transport streams), especially since the SYNC value continues where it left off afterwards, so I'd consider that an exception to the rule that SYNC values need to be continuous. I wouldn't discard it as a corrupted stream.

As for the CRC calculation, it's described in ETSI EN 302 307 section 5.1.4, but I wouldn't attempt to calculate it manually. Look up "cyclic redundancy check" on Wikipedia if you're interested.

EDIT: If all the bytes of the BB header are identical, then the computed CRC will always be the same. Therefore, it's not unusual for the CRC of these "dummy" BB headers to always be $F7.
midwestmac

Registered:
Posts: 2,275
Reply with quote  #57 
Quote:
Originally Posted by mips


Quote:
I noticed the same thing in wejones' recordings. This is purely a guess at this point but I'd be tempted to think of those DFL=$80 with SYNC=00 as dummy BB headers (similar to the null PID in transport streams), especially since the SYNC value continues where it left off afterwards, so I'd consider that an exception to the rule that SYNC values need to be continuous. I wouldn't discard it as a corrupted stream.


Thanks there were a few places with the Sync 00 not a lot. I decided to go back to the TBSrecorder. From what you were seeing with all the errors with the Streamreader and its experimental (Beta) I think crazycat posted somewhere.

Quote:
As for the CRC calculation, it's described in ETSI EN 302 307 section 5.1.4, but I wouldn't attempt to calculate it manually. Look up "cyclic redundancy check" on Wikipedia if you're interested.

EDIT: If all the bytes of the BB header are identical, then the computed CRC will always be the same. Therefore, it's not unusual for the CRC of these "dummy" BB headers to always be $F7.


Thanks I'll re-read that and check out the cyclic "redundancy check" on Wikipedia. I was reading about check-sum but thats not the same.
I wanted to really go over this TBSrecording though so I don't waste your time.
Thanks for explaining all that

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

Registered:
Posts: 529
Reply with quote  #58 
Quote:
Originally Posted by wejones

Re the re the invalid CRCs you find in this and other recordings, I'm wondering if perhaps this might be expected.  I can't remember which document, but I seem to remember reading something in one of the documents posted in this thread, to the effect that particularly with ACM transmissions, that it was likely to have fragmented data when modes switched. I think the document was trying to explain how that would be handled at the receiver, but I didn't understand what I was reading.

  I don't suppose that there is any way to tell from this data when there was a switch in modes?  Not likely I guess, but if there was, it would be interesting to see if perhaps the errors showed up when it switched to 32APSK or something like that?

Related to fragmented data, if that is the case, we should try to find the document describing it.

I know there can be fragmentation of the GSE packets, but I haven't read anything about BB frames fragmentation. Since I'm strictly parsing BB headers ATM, fragmentation shouldn't be an issue. But I could also have missed something in the spec.

As for knowing when there's a switch in modulation modes, it might be possible to tell if the MODCOD field (from ETSI 302 307) was recorded, but I don't think it currently is. Perhaps there's a setting to enable this though. If I understood this correctly, each BB header would be preceded by 2 bytes, the first of which would be 0xB8.

mips

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

I wanted to really go over this TBSrecording though so I don't waste your time.


Here's what I basically do:
1. Generate the log file
2. Search for "CRC0". If found, stream is corrupted. Otherwise, continue to next step.
3. If you're dealing with a GS-C MIS ACM stream, then I would search for the other terms (e.g. GS-P, GS-HE, TS, SIS, CCM). If found, verify is stream is corrupted by looking near location found. Check for SYNC continuity, hidden BB headers, etc.  If none of those terms are found, it means all the BB headers use GSE-C MIS ACM, and there's a better chance your recording is valid.

Of course, if your recording were TS SIS, I'd look for terms GS-C, GS-P or GS-HE, and MIS.
andyinyakima

Avatar / Picture

Registered:
Posts: 1,520
Reply with quote  #60 
I am starting to think much of the corrupted streams might be from the ACM/VCM switching.
Also if you concentrated on the 16apsk transponders you are more prone to error prone BBFrames, because your gain has to be higher.

I am finding more consistency with 12174 V 4172 on 123 W like below:

27965526 42 00 00 00 1a c8 9c 00 00 e2    e3 55 00 05 83 21 21 f6 2d e4

27966768 42 00 00 00 1a c8 9f 00 00 b2     e3 55 00 05 83 40 91 12 a1 83

27967037 42 00 00 00 1a c8 a0 00 00 5c    e3 55 00 05 83 7c 6f 11 c5 6d

27967592 42 00 00 00 1a c8 a3 00 00 0c    e3 55 00 05 83 6c 47 25 31 1b

27968311 42 00 00 00 1a c8 a5 00 00 ac    e3 55 00 05 83 7f 58 71 bf 9c

27968698 42 00 00 00 1a c8 a6 00 00 fc     e3 55 00 05 83 8b 5f a3 b4 31

27969143 42 00 00 00 1a c8 a7 00 00 7f     e3 55 00 05 83 af ac 5d 82 c2

27969604 42 00 00 00 1a c8 a8 00 00 ba    e3 55 00 05 83 eb 0c dc 6d 35

27970169 42 00 00 00 1a c8 a9 00 00 39    e3 55 00 05 83 bd 27 47 ad 80

27970489 42 00 00 00 1a c8 aa 00 00 69    e3 55 00 05 83 a7 d1 03 d7 5f

27970684 42 00 00 00 1a c8 ac 00 00 c9    e3 55 00 05 83 d2 d2 e9 71 f2

27970787 42 00 00 00 1a c8 ad 00 00 4a    e3 55 00 05 83 2d f7 f8 57 61

27971130 42 00 00 00 1a c8 ae 00 00 1a    e3 55 00 05 83 00 90 6b a0 e3

27971548 42 00 00 00 1a c8 af 00 00 99     e3 55 00 05 83 af 80 c8 be d9

27972595 42 00 00 00 1a c8 b2 00 00 96    e3 55 00 05 83 df 2d 88 de a8

27973017 42 00 00 00 1a c8 b3 00 00 15    e3 55 00 05 83 4e 0d 8c 65 ad

27973342 42 00 00 00 1a c8 b4 00 00 36    e3 55 00 05 83 c0 9b cc 9b 41

27973656 42 00 00 00 1a c8 b5 00 00 b5    e3 55 00 05 83 c6 46 a3 c0 9f

27974322 42 00 00 00 1a c8 b8 00 00 a3    e3 55 00 05 83 82 38 ce a9 ce

27974910 42 00 00 00 1a c8 b9 00 00 20    e3 55 00 05 83 93 da 1a 17 67

27975201 42 00 00 00 1a c8 ba 00 00 70    e3 55 00 05 83 32 d0 85 ff 82

27975669 42 00 00 00 1a c8 bb 00 00 f3     e3 55 00 05 83 88 fd 0a fd 35

27976431 42 00 00 00 1a c8 bd 00 00 53    e3 55 00 05 83 d6 c2 81 27 9c

27977002 42 00 00 00 1a c8 be 00 00 03    e3 55 00 05 83 65 61 ba 21 cf

27977944 42 00 00 00 1a c8 c0 00 00 0a    e3 55 00 05 83 70 4b 6d b4 12

The first number is the position in the save array file
the second series is the 10 byte BBHeader (you may notice the DFL is constant 1a c8, the SYNC follows a sequential pattern, but still has voids)
the third series is what I believe is the GSE header, it also has a consistency up to 05 83.
Looking at the binary with Hex editor shows no clues as to what is being transmitted so I don't know that it is not a private transponder and scrambled.

mips can you tell what type of file it would be if I can get a longer trailer after the e3 55 00 05 83.
Or do you believe it is still error prone? Have you been able to assemble any PDUs? partial?

I am under the assumption that the AV files are going to be on the 16apsk transponders because of the increase efficiency , but those will also the transponders with the missing or corrupted packets.

Don't know??


__________________
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!
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!