#1 2015-04-12 13:03:15

jweers
Member
Registered: 2015-04-12
Posts: 10

not quite right so far... :(

Hi,

I've been trying to get a aprs tracker built for the last couple of weeks.   It's a single Arduino Nano,   a GPS module, an OLED display and discrete parts to make the modem.
But, as of this morning I still have a couple of problems.

First, the PTT circuit (hooked up to a baofeng uv-b5) seems to work just fine on 400Mhz.   However, down on 140Mhz, it will start to transmit and then never disengage.   I assume it's pulling enough current that the transistor (2n7000) won't break the connection when the pin goes low.   

Second,
When I hook two of these together using line out, my aprs packets from the primary are only very periodically decoded.   When I've actually broadcast packets, the digipeater in the area also doesn't seem to like them.   I used mic level for the transmission.

I'm using the LibAPRS from Github and the TInyGPS library I've seen used all through the forum and again, most of it seems to work properly.  Even scoping line and mic level outs does look correct to me.   I can see the modulation and proper voltage swing in both cases.

I guess the second problem, could be related to the circuit I put together using the example on the LibAprs page.   The one notable difference I had was not having a 4.7uf electrolytic to put on the output, but I did have a 1uf and a 10uf.  I've tried both in place with no real difference in behavior.     It looked like the circuit was only using the capacitor to ac couple the signal on the output, and so I didn't think the value would matter all that much.   Beyond that, the circuit uses 5% resistors of proper values.

Any thoughts to get me pointed in the right direction?    The second libAprs type modem I hooked up (to test receiving) does manage to decode about 1 out of 20 packets or so as sent from the first unit with the GPS/Display/etch....

Thanks in advance.

John/KG7LCN

Offline

#2 2015-04-13 04:22:48

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: not quite right so far... :(

jweers wrote:

Any thoughts to get me pointed in the right direction?    The second libAprs type modem I hooked up (to test receiving) does manage to decode about 1 out of 20 packets or so as sent from the first unit with the GPS/Display/etch....

John/KG7LCN

Dear John..

Let me start with Tx side :-

Let me share my experience on this matter...
I've been building quite a few MicroAPRS circuits and selling them together with my SVTrackR (2 x mini pro solutions) ..

I have tried both LINE LEVEL and MIC LEVEL and this is the results I get :-

LINE LEVEL, almost 90% of the packets was decoded by nearby iGate / digipeaters ... ( we are suppose to use MIC LEVEL to the handy )

MIC LEVEL, the % of packets decoded was too low be to acceptable ....

( I can give you an estimated % of packets decoded as my SVTrackR have a sequence number for every packet transmitted ... )
http://aprs.fi/?c=raw&call=9W2SVT-8

So for me, using mic level out is totally not suitable ... too low when it reaches the igate/digipeaters ( I'm using a much "better" China radio Wouxun KG-UVD1P )


On the Rx side :-

I was learning about op amp and added a MCP602 into the Rx circuit... nothing fancy  , no filtering, just amplify the AF out 100/1 from the handy to the op amp before going into Analog0 pin... ( I can send you the test circuit if u r interested, I am still learning about op amp )

From the lowest AF OUT ( from handy ) level to the highest level, the AF OUT after the op amp is consistent into the mini pro A0 pin ... ( Peak to peak 4V on my oscilloscope )

With this MCP602 in place, the Rx packet decoding is almost 100% when using the APRS Test CD .... ( will plan to add this to the future PCB soon ) ...


As for the 2N7000 MOSFET, you can test if your 2N7000 is working by a circuit tester...  no one else seem to have this issue you are facing ....

Do post here again if you faces similar issues...

73


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#3 2015-04-14 03:27:37

jweers
Member
Registered: 2015-04-12
Posts: 10

Re: not quite right so far... :(

I switched out the 100k/1k divider for a 100k pot/1k divider and the audio signal coming out is much better after tweaking the knob a bit.

Then I played with a few different antennas and found that a j-pole worked on low power in the 145Mhz band.   That told me my coupling capacitor choice for the audio was poor.  I replaced it with a 10uf cap and now the PTT circuit works on low/high power with a jpole and low power with the rubber duck.    At high power with the duck it still won't stop transmitting which tells me that I'm still getting some reflected power back down to the circuit...   not yet perfect, but better and now I think I know what's going on.

Decoding line to line with a pair of the modems still has a really low success rate.   20% or so. 

And now I'm off to check my transmitted packets and see if anything was decoded...

Stanley, can you explain your op amp circuit a bit to me? Or show me a schematic?

Thanks for the help so far.
-John

Offline

#4 2015-04-14 04:07:54

jweers
Member
Registered: 2015-04-12
Posts: 10

Re: not quite right so far... :(

and packets can be decoded, but i get an invalid location

[Invalid uncompressed location]

Offline

#5 2015-04-14 06:55:43

PA3BAS
Member
Registered: 2014-12-01
Posts: 20

Re: not quite right so far... :(

The problem with the Baofeng handheld not stopping transmitting is something i heard before. It als happens with cheap earbuds with ptt... Maybe do something with ferrite?


I get some results googling "Baofeng stuck"

Last edited by PA3BAS (2015-04-14 07:01:55)

Offline

#6 2015-04-14 15:04:48

jweers
Member
Registered: 2015-04-12
Posts: 10

Re: not quite right so far... :(

Thanks... I'll put a ferrite choke on the cable to see what it does when I get off work tonight.

Also, I did finally get a few packets to decode properly late last night.   Still not quite a high enough percentage for production work, but it's at least functional now.

Offline

#7 2015-04-15 00:02:37

jweers
Member
Registered: 2015-04-12
Posts: 10

Re: not quite right so far... :(

And the ferrite choke resolves the issue.   However, my packet decode rate by the digipeater is still really low.  Although, some is better than none.. wink

Offline

#8 2015-04-15 05:07:24

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: not quite right so far... :(

Here is the single power supply op amp circuit using MCP6002 ( or any suitable op amp )

Vcc/2 is 2 x 10k to Gnd and Vcc to bring the 5V to 2.5V

R1 = 1K or 10K
R2 = 100K
R3 = 1K

You can adjust R2/R1 for the gain you needed ...

Vin is from AF-In
Vout goes into Analog0 pin

16530982084_7ed0737b1b_n.jpg

I'm still a beginner in op amp circuits, if anyone spotted any mistake, pls correct it...


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#9 2015-04-15 06:19:15

jweers
Member
Registered: 2015-04-12
Posts: 10

Re: not quite right so far... :(

Thanks for the op amp circuit..

I'm still working through packet decoding issues by the digipeater here.. 
I did post the code and schematic in case someone is interested..

https://github.com/jweers1/Aprs-Tracker

.

Offline

#10 2015-04-15 17:04:16

jweers
Member
Registered: 2015-04-12
Posts: 10

Re: not quite right so far... :(

In my code, I'm using just the one Nano for everything.   

I have software serial running the GPS on 2 digital inputs at 9600kbps.
I use regular serial at 9600kbps to output diagnostic information.
I use I2C for a u8g display.

would any of those things cause the locationUpdate routine to not work correctly?   maybe by interrupting it? 

that might explain a low percentage decode rate even using the direct audio out...

--John

Offline

#11 2015-04-16 05:16:52

jweers
Member
Registered: 2015-04-12
Posts: 10

Re: not quite right so far... :(

Low decode percentage seems to be an antenna function.   After switching it out to a much better antenna the decode rate is nearly 100%.

Offline

#12 2015-04-20 14:37:03

AJ4ZS
Member
From: Mobil, AL
Registered: 2014-12-13
Posts: 6

Re: not quite right so far... :(

John,

I tried to use GPS with softserial just like you did. But for whatever reason my Arduino got stuck after a while.
I noticed that when I used the TNC test CD it only worked for a few seconds and when I had it "live" it sometimes worked for a few minutes. I presumed that there is a conflict between the APRS Lib and the Softserial lib...
Did you notice any of these problems?


vy 73 de Hermann AJ4ZS / DL8MCP

Offline

#13 2015-04-22 01:17:28

jweers
Member
Registered: 2015-04-12
Posts: 10

Re: not quite right so far... :(

Hi,

I haven't noticed that problem.  Mine seems to work for more than 30 minutes easily...

John

Offline

#14 2015-04-22 07:58:33

markqvist
Administrator
Registered: 2014-12-01
Posts: 112

Re: not quite right so far... :(

Hi!
Have a look at the "Basic usage" example in the current LibAPRS. The aprs_msg_callback() shows you how to copy the received packet to a new place in memory before processing it. If you don't do this, that might be the reason it's crashing. This is why: If you just pass the reference to the incoming packet to another function and start processing it, the data here might change while you are doing something with it, leading to a memory conflict which could crash the MCU. I don't know if you are already doing it this way, but just a thought wink

Offline

#15 2015-04-22 20:36:11

AJ4ZS
Member
From: Mobil, AL
Registered: 2014-12-13
Posts: 6

Re: not quite right so far... :(

Mark,

I am using most of the code from that example however I noticed that when the softserial is not active the decoding works over a long time... If I monitor the free memory I can see that it fills up until it crashes. I will do some more tests and report back.

Is there any way to run LibAPRS on an ATMEGA644? This would solve the UART problem...


vy 73 de Hermann AJ4ZS / DL8MCP

Offline

#16 2015-04-23 10:24:00

markqvist
Administrator
Registered: 2014-12-01
Posts: 112

Re: not quite right so far... :(

I don't see any reason that it shouldn't run, but for now I haven't implemented support for the 644 specifically. Maybe it works out of the box, have you tried? I can't remember how different the setup is on the 644.

Basically there is two things in LibAPRS that would need to be adjusted to work on the 644 to make it work. There is this section in device.h:

// Port settings
#if TARGET_CPU == m328p
    #define DAC_PORT PORTD
    #define DAC_DDR  DDRD
    #define LED_PORT PORTB
    #define LED_DDR  DDRB
    #define ADC_PORT PORTC
    #define ADC_DDR  DDRC
#endif

And then there is the ADC initialization in AFSK.cpp:

void AFSK_hw_init(void) {
    // Set up ADC

    AFSK_hw_refDetect();

    TCCR1A = 0;                                    
    TCCR1B = _BV(CS10) | _BV(WGM13) | _BV(WGM12);
    ICR1 = (((CPU_FREQ+FREQUENCY_CORRECTION)) / 9600) - 1;

    if (hw_5v_ref) {
        ADMUX = _BV(REFS0) | 0;
    } else {
        ADMUX = 0;
    }

    ADC_DDR  &= ~_BV(0);
    ADC_PORT &= ~_BV(0);
    DIDR0 |= _BV(0);
    ADCSRB =    _BV(ADTS2) |
                _BV(ADTS1) |
                _BV(ADTS0);  
    ADCSRA =    _BV(ADEN) |
                _BV(ADSC) |
                _BV(ADATE)|
                _BV(ADIE) |
                _BV(ADPS2);

    AFSK_DAC_INIT();
    LED_TX_INIT();
    LED_RX_INIT();
}

These two sections would need to updated to reflect the port layout and the ADC init of the 644. Unfortunately I don't have a 644 myself to test with at the moment.

Offline

#17 2015-04-23 13:43:44

AJ4ZS
Member
From: Mobil, AL
Registered: 2014-12-13
Posts: 6

Re: not quite right so far... :(

I tried to compile the sketch for the microduino-core+ a while ago and it did not work. I did not pursue the matter further but I will try the changes you suggested and report back.


vy 73 de Hermann AJ4ZS / DL8MCP

Offline

#18 2015-04-23 19:46:45

markqvist
Administrator
Registered: 2014-12-01
Posts: 112

Re: not quite right so far... :(

Let us know how it goes! If you can figure out the correct portmaps and inits for the 644 I can add those changes back into the main repo!
I also forgot to say that if you observe the free memory slowly getting lower, you definitely have a memory leak which is causing the crash. Make sure you free any allocated variables after use!

Offline

Board footer

Powered by FluxBB