开云体育

Hello

We have multiple nodes running LinBPQ and I am interested in automating backup of all nodes to a central FTP site.

Beside de config bpq32.cfg what other files should be backup so if a new image is installed in the raspberry pi copying the set of files will have the node/bbs/user/chat/routes working as before?

-- 
Gracias 73,

Heber
NP4JN

Hi John,

I'm using 64 bit Windows 11.

Thanks
Matthew?

开云体育

Matthew,

I can reproduce the problem on my Pi 4 (64 bit) but not my Windows machine. What platform are you using?

Thanks,
John

Hi Red,

Thanks for spending the time to verify and document the issue.

Much appreciated

Matthew

For reference:

Here is me reproducing the bug Matt reported:?

Note: 1200 baud tested in video, but also tested 300 baud as well, same results.

73
Red

On Fri, May 19, 2023 at 02:26 PM, Matthew 2E0SIP wrote:

Hi Red,

Latest recordings attached, unproto frames with the 80 char string "FqWFkDtfi7m81dnPDb0kFqWFkDtfi7m81dnPDb0kFqWFkDtfi7m81dnPDb0kFqWFkDtfi7m81dnPDb0k"

Just to clarify the other recordings were also unproto frames.

Thanks
Matthew

?

Matt, John- I opened these files and cut the static out and then played them over the radio and managed to decode only the FX25 packets, the standard AX25 do not decode at all so same findings as Matthew, so something may be up with the preamble/TXDelay issue we encountered when you initially implemented IL2P.?

The FX25 packets decoded:

Hi Red,

Latest recordings attached, unproto frames with the 80 char string "FqWFkDtfi7m81dnPDb0kFqWFkDtfi7m81dnPDb0kFqWFkDtfi7m81dnPDb0kFqWFkDtfi7m81dnPDb0k"

Just to clarify the other recordings were also unproto frames.

Thanks
Matthew

?

On Fri, May 19, 2023 at 09:44 AM, Matthew 2E0SIP wrote:

Hi all,

Both recordings sound the same and look the same on Audacity, and both decode on both the original Soundmodem and QtSM.

It looks like both those packets might have had FX.25 enabled. Please find attached a new recording with FX.25 Disabled that the NinoTNC can't decode.

Nino KK4HEJ has also tested the packet in question and wasn't able to get it to decode.

?

Extra decoders are set in the Modem config tab in the Add Rx n pairs box.

Found it, Thanks

?

Thanks

Matthew

2E0SIP

To my ear that doesn’t sound right.?
There’s maybe a missing tail as well.?

Could you record some longer packets, possibly unproto with 80 chars.

I have a hunch that unproto might be a different story.

73
Red

Hi all,

Both recordings sound the same and look the same on Audacity, and both decode on both the original Soundmodem and QtSM.

It looks like both those packets might have had FX.25 enabled. Please find attached a new recording with FX.25 Disabled that the NinoTNC can't decode.

Nino KK4HEJ has also tested the packet in question and wasn't able to get it to decode.

?

Extra decoders are set in the Modem config tab in the Add Rx n pairs box.

Found it, Thanks

?

Thanks

Matthew

2E0SIP

开云体育

Extra decoders are set in the Modem config tab in the Add Rx n pairs box.

These are not needed on FM. On SSB tuning has to be within about 30Hz for packets to decode successfully. This amounts to a TX to RX accuracy of around 2 parts per million on 20 Meters. Modern rigs are usually that stable, but do not always have that accuracy. So QtSM can add extra decoders tuned +- 30 Hz from the nominal. I find two pairs (a total of 5 decodes) is usually enough for normal HF operation. Each extra pair adds to the cpu load so if you are running several modems on a relatively slow platform like a Pi 3 you may need to check that you aren't overloading the cpu.

QtSM reports the success of each decode in the form [--+++]. This shows that the top 3 decodes were successful, suggesting the station was around 30 Hz high. If all stations appear either low or high it may mean you are a bit off frequency. If you see stations that are always? on the edge (eg [----+] than maybe you need more decodes (or to persuade the other station to move a bit!)

73,
John

开云体育

Hi Matthew.

Both recordings sound the same and look the same on Audacity, and both decode on both the original Soundmodem and QtSM.

The packet is too short to be send as fx25, so I'd expect them to be the same.

I'll do some more tests here with longer packets and see if I can reproduce your problem

73,
John

Good stuff,

Can you record the same test output from Direwolf?

Cheers
Red

I grabbed the audio out the back of the receiving radio and attached them to this message. There's no drop outs so I guess they were a result of trying to be clever and using audio loop backs for the recording.

Hopefully these are a bit more useful.

Thanks

Matthew

I've just listened back to those and there's some drop outs in the audio I missed first time.

They were recorded with QTSM outputting to a loopback and then recorded with Audacity. I don't get the drop outs using Dire Wolf in the same configuration.

I'll try to get a recording out the back of the receiving radio tomorrow instead of messing around with loopbacks.

Thanks

Hi Red,

Thanks for the debugging tips.

?

Make sure you’re only running 1 extra pair of decoders per port on QtSoundModem if running on SSB

I'm not sure where this is configured? I've not enabled any.

Make sure IL2P isn’t enabled as well as FX25 on a single port.

IL2P is disabled on both sides (QTSM and the NinoTNC)

?

Try fiddling with the extending the TXDelay in normal AX25 mode.

I set it to 500ms to rule out any issues and it didn't help.?

?

I've attached the WAVs. Both are the string "Hello" sent 3 times.

?

Thanks

Matthew

2E0SIP

?

?

?

Matthew, for a quick tip-

Make sure you’re only running 1 extra pair of decoders per port on QtSoundModem if running on SSB. If not running SSB, set extra pairs to zero. If you have too many pairs it taxes the CPU and will cause decodes to fail.

Make sure IL2P isn’t enabled as well as FX25 on a single port.

I know several of my peers are using QtSoundModem .62 without problems on VHF, I even had someone on MultiPSK connecting in on HF before changing them to UZ7HO SoundModem and then QtSM to add IL2P.

Sounds like a weird problem, we may need to investigate further.?
Can you do some recordings of packets you’re picking up for analysis?

The NinoTNC is dip-switched as far as I know and either has IL2P or only standard AX25. It decoding FX25 packets is just the backwards compatibility working and perhaps the extended TXDelay/preamble is enabling the transmitter to open up the carrier on transmit. Try fiddling with the extending the TXDelay in normal AX25 mode.

-Red

Hi all,

I've been setting up the latest QtSoundModem Beta and found other systems couldn't decode the packets it sent, but if I used Direwolf with the exact same hardware packets were decoded as expected. This is standard plain old 1200 baud AFSK with 1200/2200 tones.

I know some work has been done recently to add IL2P support so I thought I'd try enabling and disabling it, as well as FX.25, in case something had become "stuck". Well, sure enough with some trial and error, it turns out if I enable FX25 RX+TX the other station can decode the packets. But here's the kicker, I'm pretty sure the NinoTNC used at the other station doesn't support FX.25, so it's not the case that the FEC is improving an otherwise poor link.

With this in mind I downloaded 0.0.0.56 from??and packets are decoded out of the box without FX.25 enabled.

Has a bug been introduced in the latest beta??

Thanks
Matthew

2E0SIP

hI kk6qms
I forgot to answer your GUI question
GUI means Graphical User Interface, means you have Icons or a tab to start a program
Non GUI means you start a program via a terminal command line

regards
Ken G7VJA