¿ªÔÆÌåÓý

Pi-FM APRS Tracker?


 

I had a thought about daisy-chaining a few utilities to make a Pi-FM APRS tracker.? I have not tested this yet and I am sure that there will be problems with this many links, but has anyone done something similar to this or have any thoughts?

This would be the setup:
digital mode encoder-->soundcard TNC-->teewav-->pifm_sstv-->transmit

Dire Wolf soundcard TNC and APRS tracker:


teewave virtual soundcard output to wav file:


pifm_sstv script:



Rob
KD0FTJ


 

I had a thought about daisy-chaining a few utilities to make a Pi-FM APRS
tracker. I have not tested this yet and I am sure that there will be
problems with this many links, but has anyone done something similar to this
or have any thoughts?


A test utility, included with the Dire Wolf software TNC application, can
generate the audio for a given packet in the usual monitor format.

It's normally not built as part of the installation process. First you must
compile it:

$ make -f Makefile.linux gen_packets

Put the text representation of the packets in a file or just pipe it thru
stdin like this:

$ echo -n 'WB2OSZ>WORLD:Hello, world!' | ./gen_packets -o x.wav -

The resulting audio is now in x.wav. We can also take that audio and
extract packet data from it but first we need to build the standalone
demodulator.

$ make -f Makefile.linux atest

Don't worry about the error messages. All we care about is the "atest"
executable file

Audio can be turned back into text like this:

$ ./atest x.wav


There is a bug in the current version of gen_packets where it will use a
builtin test message rather than reading from stdin. That's good enough to
get started with testing the concept.


 


A test utility, included with the Dire Wolf software TNC application, can
generate the audio for a given packet in the usual monitor format.

Cool... Thanks!


$ echo -n 'WB2OSZ>WORLD:Hello, world!' | ./gen_packets -o x.wav -

1200 baud only? Any chance of getting the other speeds - 300, 2400,
4800, 9600?



Bill, WA7NWP


 

1200 baud only? Any chance of getting the other speeds - 300, 2400, 4800,
9600?

Use "-B 300" or "-B 9600" command line options.


 

Dear friends,
the attached file is the new release of the NBFM program, the narrow-band FM transmitter, for Raspbian distro.

Changes:
- name of program now ./nbfm (was ./nbfm.out Please modify your scripts).
- text frame and colors
- DMA used for higher frequency resolution (now <1kHz on 2m, was >10kHz)
- compiler optimization
- sub/audio tone frequency adjustment
- added output power level control

It would be very interesting if someone could give me reports on how it works on the field.
For example, the packet generator would be an interesting item to test.

As I've already said, the modulator is done using the DMA and it can't be so linear, but not only, because it also generates a lot of spurs.

Even if it charges more the CPU and degrades the modulation quality, the advantage of using higher sampling rates is the reduction of the spurs (that are not the harmonics).
Regarding this, please take a look at the following table, for 145MHz band (no subtone):

Sampling rate???? CPU load??? Output Power
?? 11025???????????? 10%???????? -3.2dB
?? 22500???????????? 16%???????? -0.7dB
?? 44100???????????? 29%???????? -0.2dB
?? 88200???????????? 48%????????? 0.0dB

That is to say if I have a 250mW amplifier, I can achieve about 250mW at the nominal frequency when using 88kHz sampling.
When, in the same conditions, I use 11kHz sampling, the output power is distributed more then a half to the spurs and less then a half to the nominal frequency (-3.2dB).
So my advice would be to use 22kHz, when spurs create problems, because it's a good compromise between modulation quality and spurs.

Up to 6m band (50MHz) the spurs are low so no problem to use 11kHz for sampling, and also the modulation is better because of the higher resolution.

73s
Ale
IK1PLD