Error on Winterhill start-up

[gu6efb]

Hi

I have just rebuilt the SD card for the Winterhill and have follow all of the instruction very carefully 3 times now but each time I end up with this error

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.


Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.

VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)
<>
<>
[00a98b98] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[013f7b98] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[0045db98] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[00357b98] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
<>
<>
<>
<>
<>
<>
<>
<>
<>
<>
<>
<31457286>
<29360134>
<25165830>
<27262982>
<>
<>
<>
<>
<33554435>
<23068675>
**********
31457286
29360134
25165830
27262982
**********
[9e30c648] mjpeg demux error: cannot peek
[a000e340] mjpeg demux error: cannot peek
[9e3213c8] avcodec decoder error: unspecified video dimensions
[9e5129d8] gles2 gl: Initialized libplacebo v2.72.0 (API v72)
[9e510708] mmal_xsplitter vout display error: Failed to open Xsplitter:mmal_vout module
[9e3213c8] avcodec decoder: Using DRM Video Accel for hardware decoding
[9e3213c8] main decoder error: buffer deadlock prevented
[9dd0e428] mjpeg demux error: cannot peek
[9ed0e2e0] mjpeg demux error: cannot peek

I don't thin that I have missed anything any pointers to what I may have missed?
I am using the PI OS from the manual and it downloaded 2209-06- raspios-bullseye-armhf 32 bit
On start up of the PI connected to a local screen it all starts ok It even's finds the beacon but no video or sound

Many thanks

Keith GU6EFB

[G4EWJ]

You need the legacy version of Buster with desktop. Bullseye gave problems when it first came out and it doesn't seem to have improved.

https://www.raspberrypi.com/software/op ... -os-legacy

Brian

[G8GKQ]

Hi Keith

As Brian says:

You need to use the Buster "oldstable" OS, not the newer Bullseye. The correct link is here:
https://downloads.raspberrypi.org/raspi ... mhf.img.xz

Sorry, I'll amend the GitHub page when I can.

73

Dave

[gu6efb]

Hi Brian and Dave

Thanks for the info I was wondering if the OS or VCL that may have been the issue.

The strange thing is, after it not working I left the unit to one side but power up waiting to see if anyone could shed some light on the issue but then
it came to life and all work very well better than before if it makes any sense.

I will leave it as is for the moment and se what happens if it misbehaves I will use the older OS version.

Thanks both for your help

73 Keith GU6EFB

[G4EWJ]

Keith, I saw your comments on the net.

It's possible that the RPi is running out of cpu resources, Try this mod and see if it improves. The line may appear more than once, so just change one of them.

viewtopic.php?f=136&t=7991&p=30915&hilit=fkms#p30915

Can you run in AnyHub mode, which will send transport streams to a PC rather than using VLC on the RPi? Use QuickTune and the whpcviewer program on the PC to view the 4 streams. Edit the winterhill.ini file on the RPi to change the WH mode.

Log in with ssh and do:
nano /home/pi/winterhill/winterhill.ini
Change the BOOT parameter to anyhub
CTRL-X Y ENTER to save and exit
sudo reboot

https://wiki.batc.org.uk/WinterHill_Rec ... C_Software

If this works OK, it will rule out any problem with the non-RPi parts of the WH.

Brian

[gu6efb]

Hi Brian

Thanks for the info.
I am already running the Winterhill using your suggested configuration.
The Winterhill is running in the ANYHUB mode and headerless, but I now have the Winterhill working correctly.
The issues I found was partly my mistake as I had changed the LNB and had set the correct LNB offset in Robs Quicktune but the old LBN offset was still present in the Winterhill ini file.
What takes president? The LNB offset from Quicktune or the offset used in Winterhill.
Since setting the correct LNB offset in the Winterhill.ini file all now works as expected.
Thanks for your help

73 Keith GU6EFB

[G4EWJ]

Good. There's no LO setting in WH as such. It's always taken from each tuning command, so you could have 4 LNBs connected with 4 different LOs, in theory.

Brian

[gu6efb]

Hi Brian

Sorry I am confused.

In the Winterhill.ini I see the following

# The 4 lines below can be used instead of the 4 lines above, to activate the optional LNB PSU boards

COMMAND = [to@wh],rcv=1,freq=10491500,offset=9749603,srate=1500,fplug=A,vgx=hi # (hi,lo,hit,lot,off)
COMMAND = [to@wh],rcv=3,freq=10491500,offset=9749603,srate=1500,fplug=A,vgx=hi
COMMAND = 3 # a single digit causes a delay of that many seconds
COMMAND = [to@wh],rcv=2,freq=10499250,offset=9749603,srate=333,fplug=A,vgx=hi
COMMAND = [to@wh],rcv=4,freq=10499250,offset=9749603,srate=333,fplug=A,vgx=hi

It was not until I changed the offset here to match the LNB offset that I had measured did the Winterhill work as expected.
I did have the correct offset set in Quick tune.

Are you saying that the Quick tune offset should get applied to the Winterhill overriding what may have been set in the ini file if this is the case
it was not working for me. I will test again later and see what happens.

Thanks again

73 Keith GU6EFB

[G4EWJ]

>>Are you saying that the Quick tune offset should get applied to the Winterhill overriding what may have been set in the ini file

That's correct. The ini file commands are treated like any other tuning commands, so the LO has to be correct there so that the beacon is received on RX1 and RX3 and WH can do its own calibration and flash the LEDs to show reception in progress. If the LO is incorrect in the ini file, tuning commands from QT will still work, as long as the LO setting in QT is correct.

I just tried setting the wrong LO in the ini file and the correct LO in QT and there was no reception at bootup, but QT commands worked. I put the correct LO back in the ini file and the wrong LO in QT and there was reception at bootup, but commands from QT didn't work. This is what I'd expect.

If you put a screen and mouse back on the RPi and maximise the upper of the 2 terminal windows, there's some diagnostic output that includes the actual frequency that's being given to the NIM, which should be FREQ - OFFSET +/- any calibration that WH has done using the beacon.

Brian