I am not receiving any signal from the satellite and I was wondering if you had any manual or set of instructions for troubleshooting to be able to detect where the problem is coming from. We are trying to test it ourselves since we are in the development field we know the rural areas won’t have a satellite specialist.
On tuner settings it says NO LOCK and it doesn’t seem to change even though we have change the coax cable. If it was an issue of the satellite it would at least receive a weak signal because we are pointing it at the right direction and we have checked that many times. We are not sure what to do next.
I attach here the application log. It says link down, but we are not sure which link is that. Could that be the problem? How can we check that the information is arriving at the receiver from the satellite? How can we check then that the rasberry pi is receiving the information from the receiver?
Jan 1 00:00:23 orxpi daemon.err ifplugd(eth0): link is down
Jan 1 00:00:23 orxpi daemon.notice ntpd[209]: ntpd [email protected] Wed Jun 24 18:00:45 UTC 2015 (1): Starting
Jan 1 00:00:23 orxpi daemon.info ntpd[209]: Command line: /usr/sbin/ntpd -g
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: proto: precision = 3.000 usec (-18)
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: Listen and drop on 0 v4wildcard 0.0.0.0:123
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: Listen normally on 1 lo 127.0.0.1:123
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: Listen normally on 2 wlan0 10.0.0.1:123
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: Listening on routing socket on fd #19 for interface updates
Jan 1 00:00:23 orxpi daemon.err ntpd[212]: restrict: ignoring line 9, address/host ‘[::1]’ unusable.
Jan 1 00:00:23 orxpi authpriv.warn dropbear[216]: Failed loading /etc/dropbear/dropbear_rsa_host_key
Jan 1 00:00:23 orxpi authpriv.warn dropbear[216]: Failed loading /etc/dropbear/dropbear_dss_host_key
Thank you for your help and we look forward to trying out this product that could be very beneficial to many parts of the world.
Hello Mariela - - I’ve been tinkering with a DIY Outernet receiver for several months now. I live outside Washington, DC, in Annapolis, MD. The Outernet engineers are very helpful, and are working very hard to field their system. Sometimes their changes don’t quite catch up with the Discussion Groups, or Wiki.
At this time, 14 Aug 21:56 UTC, 12,177 MHz/23,000 kbaud shows no data being received and is shut down. This is unfortunately the DEFAULT setting on the current Librarian software version you probably received in the hardware package. Outernet’s new transponder on Galaxy 19 is at 11,929 MHz/22,000 kbaud, and is being receiving here at a rate of 91.27 Kbit.
Yes, I would make sure your FTA sees signals from Galaxy 19 for sure from a dish pointing perspective before you hook up the RaspberryPi.
I’m assuming your are seeing the Librarian. You’ll need to change the transponder your connecting to by going into the Dashboard and make the changes needed.
Here’s a screen picture of what you’ll see and what the changes are:
The most likely cause of no data is that the firmware that comes with the DIY kit does not have updated preset for G19. The old transponder exists, but nothing is on it.
As @kenbarbi says, the best course of action is to manually enter the new transponder settings as per the kindly provided screenshot. I’m currently updating the ORx image for RPi, and will put it online some time during the next week.
Hi,
Thank you so much @kenbarbi and @branko for your replys.
I have changed the configuration of the transponders and the bit rate and is still showing no lock.
Do you suggest any other steps for troubleshooting? You mentioned @kenbarbi that I should make sure my FTA sees signals from Galaxy 19. What is the best hardware to do this and what would be your recommendations without having to buy any expensive satellite signal device?
And @branko what can I do to make sure I have the receiver and the rasberry Pi working properly? Could I send you the activity logs?
Thank you once more for your help,
Best regards,
Mariela
Did you rotate the LNB 29 degrees clockwise (looking at the dish)? I got this value from dishpointer.com for San Francisco.
After I had good reception, I tried to play with the LNB skew and found that there was no margin of error.
In general the large dish requires careful setup concerning elevation and azimut. You need to wait several seconds before trying a new position. Try very small changes. It takes time to find the satellite. Make sure the bubble level built into the bracket is dead center and sits still nicely on top of the pipe end. It’s easy to accidentally push the level partly into the pipe. Also be aware that the azimut reading is done at the edge of the bracket.
The first sign of being close is that the quality bar goes to maybe 20%. Lock will come last.
The system log can be downloaded from the dashboard. Look under Application logs section for two buttons below the text box: one of them is labelled “Download system log”. That log should contain some information about the tuner (not) being recognized and/or initialized. If you could post that somewhere, I could look into it.
Thank you so much @mren for those suggestions. We did rotate de LNB 29 degrees, following the suggestions of dishpointer.com, but it did not change the reception. When you say;
Do you mean that the bar at the dahsboard of the library says receiving? Or do you measure this with another hardware?
@branko I tried attaching the log activity to this post but it only allows jpeg and gif format. I will try to paste it as text in a next post.
Thank you in advance for all the help,
Best
Mariela
@branko It’s not letting me paste the whole activity log but I cut the part that I think could help us know where the problem is coming from since it says link down. Do you have any technical support email where I can send the whole system log?
Jan 1 00:00:13 orxpi user.info ondd[157]: [main] tuning to 1427 Mhz 23000 KSym
Jan 1 00:00:13 orxpi user.info kernel: [ 13.944691] smsc95xx 1-1.1:1.0 eth0: hardware isn’t capable of remote wakeup
Jan 1 00:00:23 orxpi daemon.err ifplugd(eth0): started: BusyBox v1.23.2 (2015-06-24 19:49:27 CEST)
Jan 1 00:00:23 orxpi daemon.err ifplugd(eth0): using SIOCETHTOOL detection mode
Jan 1 00:00:23 orxpi daemon.err ifplugd(eth0): link is down
Jan 1 00:00:23 orxpi daemon.notice ntpd[209]: ntpd [email protected] Wed Jun 24 18:00:45 UTC 2015 (1): Starting
Jan 1 00:00:23 orxpi daemon.info ntpd[209]: Command line: /usr/sbin/ntpd -g
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: proto: precision = 3.000 usec (-18)
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: Listen and drop on 0 v4wildcard 0.0.0.0:123
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: Listen normally on 1 lo 127.0.0.1:123
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: Listen normally on 2 wlan0 10.0.0.1:123
Jan 1 00:00:23 orxpi daemon.info ntpd[212]: Listening on routing socket on fd #19 for interface updates
Jan 1 00:00:23 orxpi daemon.err ntpd[212]: restrict: ignoring line 9, address/host ‘[::1]’ unusable.
Jan 1 00:00:23 orxpi authpriv.warn dropbear[216]: Failed loading /etc/dropbear/dropbear_rsa_host_key
Jan 1 00:00:23 orxpi authpriv.warn dropbear[216]: Failed loading /etc/dropbear/dropbear_dss_host_key
Jan 1 00:00:23 orxpi authpriv.warn dropbear[216]: Failed loading /etc/dropbear/dropbear_ecdsa_host_key
Jan 1 00:00:23 orxpi authpriv.info dropbear[222]: Running in background
Jan 1 00:00:23 orxpi daemon.info init: starting pid 230, tty ‘/dev/console’: '/sbin/getty -L console 0 vt100 ’
Jan 1 00:00:39 orxpi daemon.info hostapd: wlan0: STA 7c:7a:91:1d:d9:45 IEEE 802.11: authenticated
Jan 1 00:00:39 orxpi daemon.info hostapd: wlan0: STA 7c:7a:91:1d:d9:45 IEEE 802.11: associated (aid 1)
Jan 1 00:00:39 orxpi daemon.info dnsmasq-dhcp[150]: DHCPREQUEST(wlan0) 10.0.0.70 7c:7a:91:1d:d9:45
Jan 1 00:00:39 orxpi daemon.info dnsmasq-dhcp[150]: DHCPACK(wlan0) 10.0.0.70 7c:7a:91:1d:d9:45 Maye
I see in the logs that you’ve tried Galaxy 19 preset or some custom settings, but with 23,000 symbol rate. It must be 22,000. You also want to check your LNB type. Is it North America Ku or Universal? IIRC, both are available in the US.
Correct output in system log should be:
for NA Ku LNB: user.info ondd[1154]: [main] tuning to 1179 Mhz 22000 KSym
for Universal LNB: user.info ondd[1154]: [main] tuning to 1329 Mhz 22000 KSym
In your case, it gives both different frequency and different symbolrate. If you’re not sure about the LNB, try both.
I think Branko hit the problem on the head, but, to be sure since the Geniatech Outernet shipped did not have an FTA viewing program, suggest you get the one Genitech uses. It is from www.Progdvb.com. Download and install it, then hook your computer to the Geniatech and see if you can get FTA channels. Uses the free version. Ken
Hi @mren so the LNB should rotate 29 degress clockwise looking at the dish from the beamer?
We have no lock still no matter the position we tried, shouldn’t be seeing at least some signal? I mean we have tried to calculate the elevation and the azimuth with many different instruments and methods and it always points at the same point. But I wonder if we should be seeing something else than the no lock? And the quality bar is always at 0%.
Any suggestions?
Hello @kenbarbi thank you for your suggestion. Are you recommending this to test if the receiver is actually working properly? Should we download the ProgDVB?
Thanks
