Date
1 - 10 of 10
SR-1 HVS-2 MODCOD
|
James Brown
I experienced another loss of lock on the SR-1 running just HVS-2 and discovered two things:
A warm reboot was all it needed to restore the lock I had set the MODCOD for both services but have now set it for HVS-1 alone. Can I presume this is also the right setting for HVS-2? The guide from Eumetsat was written I think prior to HVS-2. Cheers James. |
|
|
|
On 17/12/2022 10:10, James Brown wrote:
I experienced another loss of lock on the SR-1 running just HVS-2 and discovered two things:James, You need the current version of the guide: https://www.eumetsat.int/media/45995 On my HVS-2 SR1 I appear to have set 0x41000. Luck, history, judgement? No idea? But it works. On the Ayecka controller the SNR shows as 12.0 dB, and I'm surprised you're getting lock droppings. [Yes, MRTG is being done, about 10% through...] Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv |
|
|
|
James Brown
On 17 Dec 2022, at 11:32, David J Taylor GM8ARV 🏴 🇪🇺 via groups.io <david-taylor@...> wrote:Thanks David. I am actually using that guide but in the MODCOD section it does only mention HVS-1. Not sure if it mentions HVS-2 elsewhere. I need to watch my weather station events to see if it coincides with a lower SNR. The graphs are slightly misleading as it’s actually around 11.4-5 but such is the scale it looks better than it is! I wonder if a change in thresholds might help. Cheers, James. |
|
|
|
Douglas Deans
On 17/12/2022 11:32, David J Taylor GM8ARV 🏴 🇪🇺 via groups.io wrote:
On 17/12/2022 10:10, James Brown wrote:=================================================================================I experienced another loss of lock on the SR-1 running just HVS-2 and discovered two things:James, David, I tried setting the SR1 for both services (MODCOD 41000) and it made no difference at all. The active channels list is building up again something I noticed before when problems occur. Of course the temp folder contents are over 100. I am losing about 2,000 packets every 5 minutes and few are recovered. Still wonder how it worked for about 5 hours yesterday. HVS-1 (TBS 5925) seems fine although I do get a very slow build up of missed and recovered. The solution to that prior to this change was to set the TBS to all MODCODS. That was perfect. Now if I do that all hell lets loose ! Not too good with Xmas holidays coming up. Regards, Douglas. |
|
|
|
Ernst Lobsiger
On Sat, Dec 17, 2022 at 03:50 AM, Douglas Deans wrote:
Not too good with Xmas holidays coming up.Douglas, apparently you see the same problem on the TBS5925 we suffer on the TBS-6909X. I bet it's even related to what David sees as BER and bad frames on his SR1 routers. I'll setup a good old TBS-6903 and try to have a closer look at the transport streams ... @ALL, A) EUMETSAT here: https://www.eumetsat.int/eumetcast-europe-service-transponder-migration says "The service will stop on E10A-C10 on 23 December." B) EUMETSAT here: https://www.eumetsat.int/new-uplink-service-eumetcast-europe says "The HVS-2 currently uses E10A-C10 (the second transponder on E10A) and will keep being provided by the current service provider till the end of 2022." Please write to EUMETSAT OPS or personal contacts and *URGE* them to really provide E10A-C10 till the end of 2022 as they stated in B). This will give us and the Telespazio engineers 9 more days to compare and study what's wrong with the new transport streams on C3 and C4. As soon as C10 is lost everything will even get more complicated ... Ernst |
|
|
|
On 17/12/2022 11:47, James Brown wrote:
Thanks David. I am actually using that guide but in the MODCOD section it does only mention HVS-1. Not sure if it mentions HVS-2 elsewhere.Appendix A.5 and A.7 mention HVS-2, but not elsewhere. The MODCOD settings are the same for HVS-1 only, and HVS-2 only, as they both use the 16APSK 2/3 coding. What do you have for thresholds? I recall the EUMETSAT settings being rather pessimistic. I think mine are 0.2/0.3dB, which may be a little optimistic! "But it worked before"... Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv |
|
|
|
On 17/12/2022 11:50, Douglas Deans via groups.io wrote:
Not too good with Xmas holidays coming up.Indeed, not. So my worst-case steps were: - get rid of all the unwanted BAS PIDs. IIRC 100 and 500 are all you need. I set the others to "0", "Disabled". "Blocked" - set the MODCOD to 41000 - warm restart of the SR1 - restart the TelliCast This for an Ayecka SR1 to stop the BER being so high (now zero), stop the Bad Frames (now zero), and make the BAS packet loss near to zero. I think I an seeing occasional missed & recovered packets, and I think others are seeing the same. 73, David GM8ARV -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv |
|
|
|
Ian Deans
Indeed, not.=================================================================================== As a first report from myself I am presently using the SR1 for both the basic and HVS-1 service with MODCOD 41000. Up to the uplink change I was 0/0 on missed/recovered packets for all services, but I am now seeing some losses ( not all recovered ) on both services although losses not severe. In the last 7 hours since starting up I have 129/95 missed and recovered on the basic service and 147/44 on HVS-1 so not too bad but nevertheless disappointing. Might switch to 5925 or 5927 out of interest. Regards Ian. |
|
|
|
Douglas Deans
On 17/12/2022 14:58, David J Taylor GM8ARV 🏴 🇪🇺 via groups.io wrote:
On 17/12/2022 11:50, Douglas Deans via groups.io wrote:====================================================================================Not too good with Xmas holidays coming up.Indeed, not. Yes thank you David. What I cannot understand is that my simple basic system with an SR1 can now run for 3-5 hours lossless followed by 3-5 hours of up to 12,000 missed packets per hour. All done in good conditions, so excluding poor signal as the reason. I have not checked my unwanted PIDs but as I said in my previous mail setting the MODCOD to 41000 followed by warm restart produced no noticeable change to my system. HVS-1 on my TBS 5925 (and separate computer) is working well, not flawless, but very acceptable. Clearly the changes by Eumetsat are causing those problems but equally it does appear that personal station choices/settings are affecting the severity of the reception. You and I have a similar SR1 Basic set up but hugely different outcomes. Sadly everyone's was working well up to yesterday. Regards, Douglas. |
|
|
|
Ernst Lobsiger
On Sat, Dec 17, 2022 at 08:31 AM, Douglas Deans wrote:
Clearly the changes by Eumetsat are causing those problems but equally it does appear that personal station choices/settings are affecting the severity of the reception.Dear All, Dear GNU/Linuxers, this is a few lines of my /var/log/kern.log after setting up Transport Stream (TS) checks in module dvb_core: ... Dec 17 15:28:57 ganymed kernel: [ 5278.263292] dvb_dmx_swfilter_packet: 5437 callbacks suppressed Dec 17 15:28:57 ganymed kernel: [ 5278.263294] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x0 expected 0x2 got 0x8 Dec 17 15:28:57 ganymed kernel: [ 5278.264928] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:28:57 ganymed kernel: [ 5278.264932] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1f4 data1=0x81 Dec 17 15:28:57 ganymed kernel: [ 5278.264939] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 expected 0xe got 0xf Dec 17 15:28:57 ganymed kernel: [ 5278.264947] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1f4 data1=0x81 Dec 17 15:28:57 ganymed kernel: [ 5278.264949] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 expected 0xf got 0x0 Dec 17 15:28:57 ganymed kernel: [ 5278.264966] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1f4 data1=0x81 Dec 17 15:28:57 ganymed kernel: [ 5278.264969] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 expected 0x7 got 0x8 Dec 17 15:28:57 ganymed kernel: [ 5278.264983] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1f4 data1=0xc1 Dec 17 15:28:57 ganymed kernel: [ 5278.264986] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 expected 0x0 got 0x1 Dec 17 15:29:02 ganymed kernel: [ 5283.264507] dvb_dmx_swfilter_packet: 6132 callbacks suppressed Dec 17 15:29:02 ganymed kernel: [ 5283.264509] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x0 expected 0x4 got 0xa Dec 17 15:29:02 ganymed kernel: [ 5283.270071] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:02 ganymed kernel: [ 5283.270074] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:02 ganymed kernel: [ 5283.277032] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:02 ganymed kernel: [ 5283.277035] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:02 ganymed kernel: [ 5283.283996] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:02 ganymed kernel: [ 5283.283999] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:02 ganymed kernel: [ 5283.284002] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:02 ganymed kernel: [ 5283.284004] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:02 ganymed kernel: [ 5283.284007] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:07 ganymed kernel: [ 5288.268756] dvb_dmx_swfilter_packet: 4946 callbacks suppressed Dec 17 15:29:07 ganymed kernel: [ 5288.268758] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1f4 data1=0x81 Dec 17 15:29:07 ganymed kernel: [ 5288.268762] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 expected 0xb got 0xc Dec 17 15:29:07 ganymed kernel: [ 5288.268773] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1f4 data1=0xc1 Dec 17 15:29:07 ganymed kernel: [ 5288.268782] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 expected 0x4 got 0x5 Dec 17 15:29:07 ganymed kernel: [ 5288.268789] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:07 ganymed kernel: [ 5288.268791] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1fff data1=0x9f Dec 17 15:29:07 ganymed kernel: [ 5288.275725] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1f4 data1=0x81 Dec 17 15:29:07 ganymed kernel: [ 5288.275728] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 expected 0x9 got 0xa Dec 17 15:29:07 ganymed kernel: [ 5288.275743] dvb_demux: dvb_dmx_swfilter_packet: TEI detected. PID=0x1f4 data1=0x81 Dec 17 15:29:07 ganymed kernel: [ 5288.275745] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 ... ... And this is *NOT* one of my TBS-6909Xes that EUMETSAT has never tested up to now. This is a proven and EUMETSAT recommended TBS-6903 PCIe card on transponder C4 taking BAS with MODCODs set and HVS-1 with all MODCODs in a single cable setup. BTW it uses the same demod chip and almost same driver as the TBS-5927 USB box. For those who don't understand the geek expressions above. From the Linux documentation: ... DMX_BUFFER_FLAG_TEI Indicates that the Kernel has detected a Transport Error indicator (TEI) on a filtered pid. DMX_BUFFER_PKT_COUNTER_MISMATCH Indicates that the Kernel has detected a packet counter mismatch on a filtered pid. ... On a good Transport Stream (TS) you should not see lines like this for hours. TEI is about one of the worst things that can happen. Counter mismatch on PID=0x1f4 (= decimal 500) indicates trouble with BAS (and not with Harry!). In other words: This Transport Stream is crap (as I have explained before). Cheers, Ernst P.S. @Charlie, YMMV ... but still time to compare/document C10 versus C3. |
|
|