Langstone Discussion Forum

[w0iy]

Operator error! yes I'm as shocked as all of you dear readers

I neglected to copy the m2k.frm file to the Pluto. This is a separate zip to download. Following the EJECT step, both files .frm files are consumed. Therefore you MUST load both everytime.

I'm up and running now after following ALL the steps. Note to future readers: apparently BOTH m2k.frm and pluto.frm (version of your choice) are BOTH required, whether there is a change to m2k.frm or not. Versions of the 2 files are NOT synchronized.

FYI, I went back and installed 0.31 successfully, then installed 0.32 again. V0.32 comes up and runs.
If there are small nits to pick at, I don't know where they are hiding.

[g4eml]

That’s a useful bit of information. M2k.frm has never been needed before. Previous updates only needed the one Pluto.frm

M2k.frm is for a different device and not for the Pluto so I don’t see why it should be needed. Maybe you just had a bad update the first time you tried it.

[w0iy]

--> That’s a useful bit of information. M2k.frm has never been needed before. Previous updates only needed the one Pluto.frm

It would be helpful if someone else could confirm, but I'm reasonably sure of my own experience.

w0iy

[w0iy]

After spending several days fooling around, I decided to do a clean install.
New SD card, Buster lite 2020-08, ran install.sh successfully.

When I reboot now, I get 4x of the rpi color logo at the top of the first screen, I think this is different from the prior behavior of one larger logo.

When L comes up, I get a red error msg "Rx FIFO Not Responding". Occasional flash of TX rather than RX.

After exit to terminal, I ran Pluto_Test and it says that it is able to get 35 calls/sec rather than 140.

Notes:
1. I do have a USB hub with pi keyboard, mouse, USB headset attached.
2. The Pluto is now at V0.32 LED is blinking twice as usual. It is plugged into the high speed USB port.

===========
Followup, I unplugged the ethernet cable, ran PlutoTest and now I get 140 calls/sec. Still get FIFO error however.

w0iy

[g4eml]

OK on the Pluto throughput degrading when the network is connected. That confirms what other people seem to have seen on some systems. There is something that might improve that but I will leave that until you have the rest of it working.

The fifo not responding message is one of the new ones I added. It indicates that the graphics program is having problems talking to the SDR part of the code. That could be because the SDR is running slowly.

I would suggest trying without the USB hub. Plug the mouse and sound device directly into the Pi. It could be the sound device is too slow on a hub. You don’t need the keyboard.

Colin.

[w0iy]

Removed USB Hub.
Plugged mouse and headset into the pi directly.
Still get the FIFO error

[w0iy]

When I run ./Sound_Test if get device not found.

Identified typo in the .py files and fixed. Now it works. Soooo... the new error msg points out audio problems
as well as operator issues.

btw - luv the S meter and spectrum calibration marks.

Thanks much for putting up with me. I shall attempt to fill in all the holes, into which I've fallen.

[g4eml]

Glad it is working. Yes, a problem with the sound card configuration can cause the SDR programs to fail.

At least the new diagnostics seem to have helped find the problem. I will use your feedback to try to improve them.

Regarding the slow down with the network connected, I now have a suspicion that the way I am addressing the Pluto might be causing that. Currently I am using ‘ip:pluto.local’ which should always work but I think it might be slowing the transfers down because the Pi has to repeatedly find the real address. It may be that with some network configurations the lookup is very slow. Maybe specifying the real address would be better. I will investigate.

Colin.

[radiogareth]

Just a couple of 'wish-list' additions, should they be possible.....
For testing and perhaps beacon use, would a short CW message such as 'Test de XXXXXX Locator IO91Xh Pwr etc' be programmable, possibly via SSH rather than just the dot stream? Maybe some sort of basic beacon scheduler too?
Would a 'Hydra' audio mode be selectable at some point, ie produce half the audio 'deviation' to allow for the Hydra's doubling action?
Thanks
Gareth G4XAT

[G8GKQ]

Reference using pluto.local vs using the Pluto's IP address:

By default the Pluto IP address is 192.168.2.1. However this confilcts with my local network, so I have changed my (2) Plutos to be on 192.168.4.1 and 192.168.5.1.

There is a setting in the Portsdown Pluto Config menu to tell the Portsdown the Pluto's IP address. The Portsdown then always refers to the Pluto by IP. This also applies to the Portsdown Signal Generator, which will be able to drive the Pluto as a signal source in the next Portsdown release.

For Colin, the Portsdown stores the Pluto IP address in the file /home/pi/rpidatv/scripts/portsdown_config.txt in the line

Code: Select all

plutoip=192.168.4.1

Not sure if you can use this to help?

In playing around over the last few days, I have found that it is worth rebooting the Pluto if switching between different uses (Langstone/DATV/Signal Generator). There seem to be a lot registers in the Pluto that need to be reset!

Dave, G8GKQ