Possible LOF offset bug?

[psyborg55]

With neumodvb version from Dec 2021, LOF offset was different with each tune, and it was in range of 24-800 khz (could have been more or less but i only noticed it within this range). Then after some updates it is quite static, two values only, 56 and 100 khz. It is suppose to be like that or theres something wrong?

[deeptho]

It should be fairly constant if all is working well.

[psyborg55]

After having it at 100, 56 for weeks, a day or two after opening this bug it switched to 100, 112. I reset it to default with new version, and past few days its 0 for both bands. How significantly does this affect tuning of low SR transponders? I can lock 512, 542, 667 transponders in regular mode, but blindscan often fails to lock them.

[deeptho]

Obviously any error affects it. For low symbolrates. These problems are related to reducing the lock timeouts. I am making some improvements now.

[psyborg55]

I figured that out. In normal tune mode, it takes about 2.5 sec before carrier lock is detected for 542 DVBS, and about 4 sec for 666 DVBS2 transponder. Tried increasing timeout by modifying for loop values (loop that reads status), then it was spending almost 6 seconds on both transponders in blindscan mode and most of the times still failed to detect CRL lock. Only TRL lock would succeed sometimes, and within one tune attempt it would disappear and lock again for several times. In this case, when CRL got locked i got wrong mode detected DVBS2 for DVBS transponder and wrong symbol rate. I think there is something else going on, some module might need reset if it will work at all. Because, in blindscan mode, all the transponders are tuned one after another without stopping demod. And in normal mode demod is stopped and even SEC chip is powered down. There is powersave setting in tvheadend that keeps SEC chip powered up when idle. I will try to see if that makes any difference. Anyway, since the LOF offset is pretty much static as you say it works fine i'm closing this

[deeptho]

In the current version the low symbol rate muxes on 5.0W lock reliably. The difference is 1) 50kHz spectrum instead of 100kHz spectrum. 2) setting a narrower search range. The relatively long locking delay is due to the large search range and fine scanning steps, but perhaps also due to some constants. You can very: after blindscan, when tuning ythe same mux again, but without blindscan it will lock very fast.

These changes still does not lock the 185kHz mux on 30.0W (Mars radio), which does lock in stv091x, but even there it does not lock in a normal way. I have experimented with many parameters without success. At some point even the correct constellation appears for a few seconds before going out of sync.

I have made various improvements for stv091x as well. Previously unimplemented features would also result in incorrect lof computation.

stid135 and stv091x should be similar in many respects, but stid135 has a 1.3Gz bandwidth and probably some extra control loops. The datasheet is very unclear.

[psyborg55]

I have only one m88ds3103 device (should get another one soon with m88ds3103b demod) so i cant say anything about stid135 or stv091x and the following only concerns montage support. The thing is, "blindscan mode" at the moment is only with cli version of neumo. I thought neumodvb would call that app when set to do blindscan, but later found out it does not. It seems to rely on different tuning method. So i skipped the entire thing for the time being and focused on getting driver to do the blindscan with cli version as best as possible. Since the algorithm is proprietary many of the search parameters are ignored. In general, FFT will detect most of the transponders, but sometimes miss some of them as well. Possibly experimenting with FFT registers could improve transponder detection.

Main issues with this driver are status parsing of DVBS mode, low level detection of DVB system and occasional failure to lock a transponder. DVBS mode needs reading of two registers and for that reason there is no status update until there is a full lock. This seemed to work fine but i didnt like the fact i have status 0 all the time until demod locks while reading status. I also thought it might be a problem when trying to lock 500-900 symrate DVBS transponders. Then i tried to use single register for DVBS status just like it is for DVBS2. This introduced minor problems with locking of low-sr in neumodvb (such that neumodvb retunes several times before successful lock). When doing blindscan DVBS transponders started to report 6-8 mhz carrier offset which is incorrect. But the blindscan also started to lock more transponders than previously, even MIS transponders at 5w are detected as DVBS with sr 35295. I raised timeouts for sr < 1000 and now some of these are locked as DVBS2 while actually being DVBS transponders.

Datasheet claims automatic signal type detection and passing through corresponding processing path. So far i could not find a way to detect this information before locking is done. And i dont have high hopes either, most likely it is automatic internally only and not exported to userspace. Constellation monitor is mentioned as well in the datasheet, it would be really dumb if it refers to that single register indicator as a monitor function...

If the type detection really goes on automatically then it is quite possible that the driver sets tune request in DVBS2 mode, but due to a long timeout demod already switches to DVBS mode before it manage to get carrier lock which is then incorrectly assigned to DVBS2 mode, and with DVBS2 registers being set during tune request gives incorrect symbolrate and SNR info..

[deeptho]

I have only one m88ds3103 device (should get another one soon with m88ds3103b demod) so i cant say anything about stid135 or stv091x and the following only concerns montage support. Can you check if the mux at 30.0W with very low symbol rate works? See https://www.lyngsat.com/Hispasat-30W-5-30W-6.html 11695V. If you can make your driver somehow compatible with neumodvb, then that could be helpful for other users.

The thing is, "blindscan mode" at the moment is only with cli version of neumo. I thought neumodvb would call that app when set to do blindscan, but later found out it does not. There is a lot of confusion about the meaning of blindscan, but what neumodvb relies on is blind tune: the driver adjust symbolrate and frequency (BLIND) or frequency (WARM) or nothing at all (COLD) when tuning. In addition some drivers have a mode that can look for the next transponder based on some internal FFT compuation. This could be called "band scan" or "satellite scan" and also requires BLIND tune.

DVBS mode needs reading of two registers and for that reason there is no status update until there is a full lock. I think this is the same for all modulations. There are usually three important parts: 1) locking to the carrier 2) FEC or viterbi lock 3) DVB data received. As long as 1) is not ready, nothing much can be done.

This seemed to work fine but i didnt like the fact i have status 0 all the time until demod locks while reading status. I think it is best that at first you forget about functions like "read_status" when testing. Instead just call sleep(some large number) after tuning. The blindscan drivers will still call periodically the actual tune functions and this causes less confusion when debugging. You can have a look at stv091x_drv.c to see what can info can be gathered even if no lock is achieved yet. Also, in this case, yiou might have to try some pls_codes because with the wrong code nio lock can be achieved. Of course your card is the one exception that manages to find these codes by itself.

It is the least confusing example.

If the type detection really goes on automatically then it is quite possible that the driver sets tune request in DVBS2 mode, but due to a long timeout demod already switches to DVBS mode before it manage to get carrier lock which is then incorrectly assigned to DVBS2 mode, and with DVBS2 registers being set during tune request gives incorrect symbolrate and SNR info.. Usually the difference between DVBS and DVBS2 mode at the start is not much. DVBS2 just has more freedom. For instance DVBS is always QPSK and DVB-S2 can be QPSK. So DVBS-2 is a safe choice. What often can be done is to set some registers to prevent certain modulations from being checked. This can then sometimes be faster.

[psyborg55]

Can you check if the mux at 30.0W with very low symbol rate works? See https://www.lyngsat.com/Hispasat-30W-5-30W-6.html 11695V.

At the moment my range is limited to 70e - 11w. I'll need to relocate my dish. Since you mention it i remembered to ask if you can check what parameters does 11039h 1904 at 7e is using? I can kind of lock it but the neumo keeps on retuning and no data received. I found several transponders at 5w with similar behaviour

Also to add: ds3103 does not lock transponders below 500ks/s. Best i managed so far is detect 11450h at 7e with sr 403, but tuning failed in both DVBS and DVBS2 modes. Seems like DVBS mode can work a bit more stable than DVBS2 with such low sr (this afternoon i had some lock failures on 666 ks/s at 5w, in the evening it works ok again). 468ks/s at 8w i could never tune.

The thing is, "blindscan mode" at the moment is only with cli version of neumo. I thought neumodvb would call that app when set to do blindscan, but later found out it does not. There is a lot of confusion about the meaning of blindscan, but what neumodvb relies on is blind tune: the driver adjust symbolrate and frequency (BLIND) or frequency (WARM) or nothing at all (COLD) when tuning. In addition some drivers have a mode that can look for the next transponder based on some internal FFT compuation. This could be called "band scan" or "satellite scan" and also requires BLIND tune.

Thanks. This explanation makes it a bit more clear on what i need to do.

DVBS mode needs reading of two registers and for that reason there is no status update until there is a full lock. I think this is the same for all modulations. There are usually three important parts: 1) locking to the carrier 2) FEC or viterbi lock 3) DVB data received. As long as 1) is not ready, nothing much can be done.

And before carrier lock there is suppose to be stable timing lock? When i get lock failure, there is usually status 1 accross entire duration of tune attempt (FE_HAS_SIGNAL) but nothing else. I think there is a bug in symbol domain.

This seemed to work fine but i didnt like the fact i have status 0 all the time until demod locks while reading status. I think it is best that at first you forget about functions like "read_status" when testing. Instead just call sleep(some large number) after tuning.

If the driver does not read status it fails to lock on to anything. I thought i should move status read from driver to scan routine in dvb_frontend.c but several attempts to do that resulted in no lock as well.

The blindscan drivers will still call periodically the actual tune functions and this causes less confusion when debugging. You can have a look at stv091x_drv.c to see what can info can be gathered even if no lock is achieved yet. Also, in this case, yiou might have to try some pls_codes because with the wrong code nio lock can be achieved. Of course your card is the one exception that manages to find these codes by itself.

Could the above example of 11039h be the one of such transponders that need special PLS code?

It is the least confusing example.

If the type detection really goes on automatically then it is quite possible that the driver sets tune request in DVBS2 mode, but due to a long timeout demod already switches to DVBS mode before it manage to get carrier lock which is then incorrectly assigned to DVBS2 mode, and with DVBS2 registers being set during tune request gives incorrect symbolrate and SNR info.. Usually the difference between DVBS and DVBS2 mode at the start is not much. DVBS2 just has more freedom. For instance DVBS is always QPSK and DVB-S2 can be QPSK. So DVBS-2 is a safe choice. What often can be done is to set some registers to prevent certain modulations from being checked. This can then sometimes be faster.

I will spend some more time with it and if i cant make any further improvements it will be good as is. Currently it can scan astra 19.2 in less than 3 minutes. That time increases when there is more low sr transponders, especially those that can't get locked