GEOSATpro HDVR3500 - freezes on boot
- Thread starter Psikic
- Start date
- Latest activity Latest activity:
- Replies 119
- Views 17K
So I managed to get a copy of v1339 and try to do a downgrade. Even after the downgrade I still had the problem with the motor moving past the satellites. I decided this evening to connect to the box to see if I can find any output to troubleshoot, since I am not getting much help from anyone.
I ran these commands:
The software would not run, of course, since it was already running. However it told me one important thing: even though I had downgraded the firmware, the dvb executable was still at version 1344. If the 1344 software was the one that introduced the problems, and I can't downgrade the firmware, that means I am completely stuck until new firmware is released that solves the issue.
I ran these commands:
The software would not run, of course, since it was already running. However it told me one important thing: even though I had downgraded the firmware, the dvb executable was still at version 1344. If the 1344 software was the one that introduced the problems, and I can't downgrade the firmware, that means I am completely stuck until new firmware is released that solves the issue.
++++ May 11 2016 Revision: 1344 Last Changed Rev: 1344 +++++
killall: himount: no process killed
[-364759790 ERROR-hi_tuner]:HI_UNF_TUNER_Open[2251]pen /dev/hi_tuner tuner failed
I found that when the box gets stuck in an infinite loop trying to lock a channel and freezes up the box, this is repeated over and over again:
It is essentially sending the motor positioning commands over and over again, but I believe it is calculating the angle incorrectly so the dish is misaimed. Since there is no signal, it detects this and tries to send the motor command again. I see a couple of problems here: if it has sent the motor positioning once, there is no reason to send it again. Second, if it had sent the correct motor positioning, it would have acquired signal and wouldn't be in the loop to begin with. Now if I can only figure out how to convert this angle that it has calculated (53440) to the angle that EBSpro calculates for this satellite (2570) we can figure out how bad it is off.
It is essentially sending the motor positioning commands over and over again, but I believe it is calculating the angle incorrectly so the dish is misaimed. Since there is no signal, it detects this and tries to send the motor command again. I see a couple of problems here: if it has sent the motor positioning once, there is no reason to send it again. Second, if it had sent the correct motor positioning, it would have acquired signal and wouldn't be in the loop to begin with. Now if I can only figure out how to convert this angle that it has calculated (53440) to the angle that EBSpro calculates for this satellite (2570) we can figure out how bad it is off.
Can you use satellite position numbers instead of USALS? Or maybe get an ASC1 from Titanium? I would get his advice if I were you.
Edit: Oops, forgot that the ASC1 doesn't generate DisEqc or USALS. (I don't have one).
Edit: Oops, forgot that the ASC1 doesn't generate DisEqc or USALS. (I don't have one).
Last edited:
Its just a 90cm dish that has just a Ku LNB on it. An ASC1 is way overkill. I might be able to use DISEqC 1.2, but it will take me forever to get it setup and tuned right.
Can I hook up a different receiver, tune to a sat with USALS, save the DISEqC 1.2 position to the motor, and then hook the HDVR3500 back up and set the satellite to use that saved position? (using STAB HH-90).
Likely unrelated to calculated motor positioning. The current calculated USALS offset value matches the previous position value, so the motor does not move.
Upon loss of signal, most DVBS tuners attempt reestablish the signal path by repeating switch and motor control strings.
The loop could be a result of a tuner, demod or logic error(s).. If the tuner is looking at the wrong IF, polarity, mismatched satellite/satellite reference, incorrect DiSEqC/22KHz, etc.
As it was indicated that the last firmware had modified switching and motor protocol, one would assume that there is an error in this new coding.
An ASC1 would not be suitable for a HH90, as it does not generate USALS, 22Khz or DiSEqC commands.
Upon loss of signal, most DVBS tuners attempt reestablish the signal path by repeating switch and motor control strings.
The loop could be a result of a tuner, demod or logic error(s).. If the tuner is looking at the wrong IF, polarity, mismatched satellite/satellite reference, incorrect DiSEqC/22KHz, etc.
As it was indicated that the last firmware had modified switching and motor protocol, one would assume that there is an error in this new coding.
An ASC1 would not be suitable for a HH90, as it does not generate USALS, 22Khz or DiSEqC commands.
The thing is, I can set up a satellite with USALS settings, tell the box to move there. Do a blind scan, pick up everything and save it. Exit menus to viewing mode and watch the channels. I get 97% quality on NHK World on 103W after doing this, for example. It will play fine for hours. Then if I move the dish to a new sat and then later come back to 103W, it will briefly lock the TP for NHK world and get 97% Q but a few seconds later you will see the Q drop all the way to 0. I peeked outside and noticed the dish had not stopped moving until just after the Q dropped to 0. So it moved right past. So obviously it gets the position right at some point, but when I move away and then move back, it doesn't move back to the same spot. Maybe the angle calculation has an error? I tried to figure out the algorithm for it (found some of the source code for the DISEqC driver for the HiLinux boxes), but it was too complicated for me to just take a glance.
FYI, my X2 M1HD and TBS5980 don't exhibit this behavior, which is why I am convinced it is the HDVR.
Btw if any developers are interested, here is an example of the complicated trigonometry used to calculate a USALS angle, and why it is hard to get it right. Example comes from 3 year old code, I'm sure it is slightly different now...
(https://github.com/hisilicon/x5hd2-drivers/blob/master/source/msp/api/frontend/unf_diseqc.c)
FYI, my X2 M1HD and TBS5980 don't exhibit this behavior, which is why I am convinced it is the HDVR.
Btw if any developers are interested, here is an example of the complicated trigonometry used to calculate a USALS angle, and why it is hard to get it right. Example comes from 3 year old code, I'm sure it is slightly different now...
(https://github.com/hisilicon/x5hd2-drivers/blob/master/source/msp/api/frontend/unf_diseqc.c)
Is the LNB a universal one? If it is, try setting the LNB Lo to just 10600, rather than universal and see if that makes a difference. The recent "fixes" had to do with 22khz switching, maybe if 22 khz is disabled in the receiver, it might make a difference?
When you downgraded the firmware, did it have you go through and select between FTA mode and Glorystar mode, country, language, etc? IIRC, there was a few times I downgraded and it did what yours is doing, it didn't go through the pick mode, country, etc and I actually had to do the hold the buttons thing with the firmware I wanted on a thumb drive in the front USB port to get it to actually downgrade, it wouldn't do it through the menu.
I am out of the loop quite a bit here, the last firmware I used was 9XX and I haven't worked on my 3500 for quite a long time, so things could be quite different now. I know some things are different, just from what people post up about the latest firmwares.
.
When you downgraded the firmware, did it have you go through and select between FTA mode and Glorystar mode, country, language, etc? IIRC, there was a few times I downgraded and it did what yours is doing, it didn't go through the pick mode, country, etc and I actually had to do the hold the buttons thing with the firmware I wanted on a thumb drive in the front USB port to get it to actually downgrade, it wouldn't do it through the menu.
I am out of the loop quite a bit here, the last firmware I used was 9XX and I haven't worked on my 3500 for quite a long time, so things could be quite different now. I know some things are different, just from what people post up about the latest firmwares.
.
I was only addressing the boot error. Wasn't aware of your USALS motor errors.
I agree with you that the errors are related to the HDVR3500 as USALS is calculated for each call and only the "00" reference is stored in the motor.
You may be right that the USALS calculation is incorrect. USALS calculation was incorrect when I first demo'd the unit last year and the dish would drive to the Eastern limit on every satellite call.
I agree with you that the errors are related to the HDVR3500 as USALS is calculated for each call and only the "00" reference is stored in the motor.
You may be right that the USALS calculation is incorrect. USALS calculation was incorrect when I first demo'd the unit last year and the dish would drive to the Eastern limit on every satellite call.
Yes, it is a universal. (9750/10600). There is no 10600 only on the menu. I guess I could set it to 10750 and do another blind scan, since the frequencies will be off?
Yes, after downgrading I did a factory reset and got the setup wizard to choose FTA or GS mode.
10750 should work for this, I would think. The frequencies will be off like you said and some channels/ transponders won't scan in, but it should work just to tell if it makes a difference in the motor problem. You shouldn't have to rescan anything or nothing, just change the Lo and reboot the receiver and see if it works better? But then again, maybe you will have to rescan, but I think it won't even matter for this if it actually picks up a channel or not, the motor should move all right regardless of that, although it would be a lot easier if you can actually see a channel. I thought 10600 was in the menu, maybe a custom option, or something like that? Could be I'm remembering wrong. Too bad that, with 10600, you wouldn't have to rescan.
What is the file size of the firmware you're trying to load? Maybe the download was corrupted, or something wrong with it? I don't remember what the file sizes were when I was messing with my 3500, but maybe compare the size to the other firmware you have and see if they differ greatly? Maybe the firmware you're loading is messed up and so it's defaulting to the one in the receiver and just resetting itself, rather than upgrading? Really, really s@cks if you can't downgrade!
Well it froze up again while trying to save the LNB settings. And then after rebooting it is hanging on a no signal channel again. I'm tired of this POS. My $40 receiver is still better than this $165 crap box.
I came to the same conclusion last year.
SatAV, for the love of god, please either fix this thing or stop selling it.
Last edited:
Well, well. Decided this morning to plug back up box #1 because I never got a label to send it back. I telnetted into it, used my trick to clear the user settings and force a factory reset, since the box does not respond on TV outputs. Guess what, it is not a hardware failure after all. It is just showing the same two symptoms I have seen on the replacement box: freezing up on boot when it cannot lock a signal and misalignment of dish using USALS. So now I have two boxes with the bad firmware.
Because the STB tuning routine turns off the 22Khz tone to issue DiSEqC and the signal reacquisition is looping, it might be that the universal LNBF internal 22Khz band switch is not being switched to highband for long enough duration to provide tuner lock. Changing the LNB type to single with LO 10600 still requires 22Khz tone to make the signal path to the highband.
As a test, do you have a standard LO 10750 LNBF to swap?
As a test, do you have a standard LO 10750 LNBF to swap?
I did --- I had a GSP SL1PLL for a couple of weeks, but it died last week after I accidentally did a hotplug. Replaced it with an Amiko L-104 Universal 9750/10600.
Just ordered overnight from Amazon the MK1-PLL. I guess it is the exact same thing as GEOSATPro's SL1PLL and Titanium's PLL-1KS right?
Have these boot errors been happening only with the universal LNBF? I would swap to a Standard LO 10750 LNBF and test results.
In the absence of a standard LNBF, you could test using the universal. Perform a factory reset. After configuring the receiver to be a FTA unit, connect to the dish that is confirmed to be aimed at a satellite. Delete all transponders from the satellite, set the LNB type to a single LO setting (9750, 10600, etc) with 22Khz OFF. Blind scan.
This will make all found channels be from the LNB lowband setting (not many might be logged using this band).
Test to see if boot problem occurs.
The Maverick is basically the same LNBF as the 1KS and SL1-PLL
In the absence of a standard LNBF, you could test using the universal. Perform a factory reset. After configuring the receiver to be a FTA unit, connect to the dish that is confirmed to be aimed at a satellite. Delete all transponders from the satellite, set the LNB type to a single LO setting (9750, 10600, etc) with 22Khz OFF. Blind scan.
This will make all found channels be from the LNB lowband setting (not many might be logged using this band).
Test to see if boot problem occurs.
The Maverick is basically the same LNBF as the 1KS and SL1-PLL
Thanks for the tips Brian. I will try this tonight when I get home so we can rule out if it has anything to do with 22Khz. You may be onto something, especially since the fact that it is able to lock the TPs initially, but most of the time can't lock them again. I'm sure the blind scan holds the 22Khz much longer when going vertical than when doing a channel change or when trying to reaquire the signal path if awaiting for signal times out.
Much of my testing of this "bug" has been swapping between Russia Today on 97W (which is 12152 Horizontal) and NHK World (which is 11943 Vertical). If your theory holds, then I should NOT see the bug moving from a 97W Horizontal transponder to a 103W Horizontal transponder -- even leaving the Universal on and leaving it in 22Khz mode?
