How do you debug wireless?

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again folks.

For those of you who read my AX.25 post, i found the answer, but i have no way to verify that it works.

For all others....

I`m working on a student satellite project, implementing communication. I`m trying to implement a basic AX.25 protocol for SAT-Ground communication.

I have a system up and running for transmitting AX.25 packets, but every one of them is rejected by the hand-held radio. I have absolutely no idea what is wrong with it as i cant get any error code out.

I have tried to use a receiver (CC1020) to analyze the packets sent by the commercial radios, but the receiver outputs garbage.(any help here would also be fine).

So how do you debug this kind of error?

Equipment to use:

CC1070 ( transmitter chip, for the satellite)
CC1020 transceiver chip.
Some yaesu radios.
Also have stuff like spectrumanalyzers and such.

Kim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

whooops, wrong place, sorry.

Please move to general electronics....

[cliff: your wish is my command]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the hand-held do? Does it respond at all? If so, what is the response?

Can you receive and decode packets from the hand-held with your hardware? I would start there, rather than transmit.

You MIGHT do this. Find a real TNC (such as Kantronix KPC3+ - there are others, also), Put in the mode to monitor raw ax.25 packets (and to do so even if there are packet errors). Read the output on a computer and convert the data steam to hex. Transmit from your hardware to some address NOT used by the monitoring device. Use the monitoring device to capture the packets as transmitted. I hope that you remember to shift source and destination call characters by 1 bit. I say "real TNC" because the TNC inside most HTs does not have full capability.

Trying to recall the raw packet decode mode in TAPR2 TNCs, the TNC may convert it to hex for you because I think it can be read in a standard terminal.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim.

When transmitting the hand-held gives no response at all.

I have tried to receive packets from the handheld, but the receiver chip just puts out random stuff. Otherwise, thanks for the advice, i will focus on the receiving part for now.

I have not found any TNC`s to use which have the capability of just showing the raw-data. The ones i use now(don`t remember the names right now) gives either a general error counter, or nothing at all. I have verified that the receiver chip is receiving correct data by correlating the data input of transmitter with data output of receiver. Also, when holding PTT-button on the radio, the receiver is outputing a flat signal, either high or low, but not changing.

Transmitter and receiver is evaluation boards so they should work well...

Kim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check out the "soundmodem" package for Linux. It is a sound card driver that does afsk and ax.25. You could tx into the soundcard instead of your TNC. I believe there is a debug option to log everything to the console. Once that's running you may be able to use wireshark to decode the protocol packets.

Good luck.

-br

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi billroy,

I have installed the linux AX.25 packages on my laptop, but never used them.

Would it work running the signal straight from the MCU to the microphone input? Using a voltage divider of course. And the let the software push out the received data?

Kim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

br makes a good point.

You CAN connect the "audio" from your box to the sound card and use one of the sound modem apps (AGWPE is one) to debug what is being received. It can also originate.

If you get NO response at all, then the hand held is not even recognizing an address. If it recognizes that the packet is addressed to it, but everything else is bad, it will issue a NAK packet, I think. You might listen with a third radio just to see if the hand-held IS responding but your hardware is not decoding it.

As I said, I would focus on receiving and decoding known good packets from the other device. I really doubt that you are receiving "random stuff". If, for example, the hand-held sends a connect request to a specific call, does your device decode same each time, or different? If same, then you have something to work on; its "just" bad decoding. If it really IS random, then you need to look at your tone detection algorithm and stuff like that.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your audio out -> soundcard in is the theory on the inbound side. It may be as simple as a straight through audio cable but generally there's a little isolation circuit that handles keeping the DC circuits separate on the RX side and muxing the ptt and the tx. Google around for TNC Cable circuits. With luck you can get an opinion from that afsk modem + ax.25 protocol decoder about the content of your packets.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as the receiving goes, the chip is supposed to do the synchronization automatically. The output of the receiver is a clock, a signal lock, and of course the data output. The way i have checked the received data is by using a bitbanged SPI, sync is by waiting for a start-flag (0x7E), and after that just save all incoming data to a array for as long as the signal lock is active. Only random data gets out of that. I have also tried to use a peripheral SPI-unit, but the data is still random.

At the moment i do the decoding of packets manualy, after all, how much could go wrong between the flag and receiver adress? I do the decoding by reading the array trough the debugger.

I do agree with you on the part of getting the receiver to work first, but i feel i have tried all kind of settings without results. Maybe my flag detection algorithm is faulty? I`ll post some code tomorrow if you want to see how it works. Now it`s bedtime for me....

Kim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are you using for a decoder? (that is, tone to digital)

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The receiver chip does that for me, it outputs digital data and clock.

see http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=cc1020&fileType=pdf Page 25/26.

Kim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was not aware of that chip. Looks interesting. I will take a look at it in more detail and try to offer some suggestions.

The immediate thing I see is that "normal" VHF/UHF 1200 baud packet is coded NRZI. You may want to look it up in Wikipedia to see how it differs from NRZ. I don't see NRZI listed as one of the encoding/decoding systems on that chip.

In thinking about this, I hope you have a second chip because this is what I would do. I would set up the second one to transmit a steady alternating stream of high and low tones. Then I would use this as a signal source to verify that my receiver is properly detecting this alternating tone sequence properly. Then, I would construct a simple packet with framing characters and arbitrary, but known, data, and verify that the receiver properly decodes that. In essence, the second chip would be your test signal generator.

AHHH, BIG problem. REALLY BIG problem. Very fundamental. 1200 baud ax.25 uses AFSK. That chip does NOT support AFSK!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Got a point there:S

Thanks for investing time into helping me, i really appreciate it.

I`m not sure if 9600 baud also use AFSK?

I`ll have to read up a bit more...
By the way, we are using 437MHz, 9600baud.

Kim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And yes, i do have 2 chips, one of them is a transmitter only, but for testing simple communication it works. I have done the tests you mentioned, by monitoring the dataflow out of the receiver using oscilloscope. And it comes out nicely. But if it is as you say, that standard AX.25 modulation is AFSK, that would explain the randomness observed with commercial equipment.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AFSK decoding is fairly simple to implement with analog electronics, if you could turn off the decoder in the transceiver chip, using only the modem. You would need a bandpass filter with 3 taps, for the low and high tones and the mark tone. Feed those 3 taps to comparators and into a uC for software decoding. This might tell you if the receiver is at fault, if you are able to decode the data this way. I suspect such an analog filter would probably cost less for mass production as well, even with 1% precision resistors, as you could then use a cheaper modem-only chip and do the decoding on an AVR or something...

My guess is as Jim's here, either the wrong algorithm is being used for decoding, or there might also be something wrong with the clock source for one or the other chip. If both clock sources aren't accurate, it will likely shift everything from data rate to tone frequency and carrier. I would say you could simply do a small mod to your setup and use a single clock source to drive both modules just to eliminate this as a possible suspect during testing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

9600 baud uses FSK BUT...

it uses a "scrambiling" algorithm to make the average near zero. So, I am guessing that you are not descrambling it correctly (or, maybe at all). Take a look for G3RUH stuff. I believe that his algorithm is the one that is still used. It may be hard to find. I have some info on it if I can still find it. It has usually been done in hardware, so the process needs to be converted to software. I will bet that the lack of the descrambler is why you are seeing "random" stuff.

It should go without saying that you also need to scramble on transmit.

Here are some links using search for: G3RUH modem:

http://www.jrmiller.demon.co.uk/...
http://www.amsat.org/amsat/artic...
http://www.baycom.org/bayweb/tec...
http://www.jrmiller.demon.co.uk/...

Also, look at amsat.org for more 9600 baud designs as used in satellites.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Jun 20, 2009 - 10:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Unixwhore,

Thanks for the suggestion about using analog electronics for filtering, but i think that if it is possible to do everything internal in the MCU, using the hardware already chosen, that would be very good. I don`t think ESA(European Space agency) is very happy about large changes in documents.

Thanks for the links Jim, i did not know about the scrambling stuff at all. Interesting reading too. I wonder how the NCUBE did it. That was the first student satellite at my school. They did also use 9600baud. unfortunately, all their software is gone :(

Kim

Can`t wait to try out the descrambling stuff.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also google: g3ruh scrambler

You will come up with some DSP code. Not sure if it will be more work translating from hardware or from DSP, but it might be useful.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi folks, sorry for being so quiet lately, had my last exam this monday so been a tad busy.

I think i finally found the solution on how to implement this. First, the IC is not capable of doing NRZI, so this will be done in software. The chip will be programed to be transparent uart, i`m pretty sure that will work perfectly. The scrambling is also implemented in software.

As we are using a different chip for receiving, which is capable of AFSK, the implementation of that should go smooth.

Sound like a decent solution to you?

Kim