Radio Communication, Incomplete data on the receiving end

Using Arduino General Electronics
#1

I posted earlier about AFSK signals using a library called SoftModem. I moved on from SoftModem and onto one called LibAPRS. I'm a lot closer to successfully transmitting data now. I am able to communicate between the two arduinos with a wired connection, but I'm having trouble with the radio connection.

I'm losing about half of my data between the radios.

This picture is the data over wired connection. The yellow is the data and the blue is the enable pin.

Sorry it's blurry, it's about 840ms long if you cant tell.

This is what the data looks like on the radio receiver.

It's barely half as long and the ends look pretty mangled.

Not sure why the pictures aren't showing up today, but if you click on the icons it should take you to the picture.

I'm not entirely sure if this is a software or hardware issue, but I believe it's hardware, since it works with a wired connection. Could the transmitter require more time delay between the enable and the signal?

#2

" Could the transmitter require more time delay between the enable and the signal?" You must have changed the delay or you would not be asking the question. What happened when you increased the delay?

Paul

#3

Paul_KD7HB:
What happened when you increased the delay?

Paul

I tried it. No effect

#4

GustavoMcSavy:
I posted earlier about AFSK signals using a library called SoftModem.

Do you mean the AFSK works over cable, and having issues when transmitting over wireless?

For the wireless system....... are the two audio tones modulating a high frequency carrier?.....You transmit the RF signal.... and at the receiver, you recover the audio tones from the RF carrier?

Oh.... hang on..... I see now, after looking at your diagrams on the other thread. May need to see if your wireless link is allowing sustained data communications..... with no interruptions or hold-ups. Otherwise, yeah..sure, things could drop out. hmmmm....but then again, if error checking is used, then should be ok.

#5

This picture is the data over wired connection. The yellow is the data and the blue is the enable pin.
Sorry it's blurry, it's about 840ms long if you cant tell.

This is what the data looks like on the radio receiver.
It's barely half as long and the ends look pretty mangled.

..but then again, if error checking is used, then should be ok.

Talk is cheap.
Illustrate how you would do that.

#6

I have error checking, what I need is fewer errors. 0 of 10 transmissions have successfully made it through. I have a buffer on the receiver input to square up the signal, but I'm not sure what else I can do.

#7

I see. Yeah… are you using methods like manchester encoding for synchronisation? I reckon you’re really close to getting things working.

#8

I have a buffer on the receiver input to square up the signal, but I'm not sure what else I can do.

This is a bad idea. The software expects from the receiver (in the ideal case) a clean, sine wave audio signal. An analog input is used, not digital.

I suggest to closely follow the directions on the microAPRS site for coupling the receiver signal to the modem.

Micromodem input signal requirements:

Minimum analog input level for good decode is about 100mV peak-to-peak

#9

jremington:
This is a bad idea. The software expects from the receiver (in the ideal case) a clean, sine wave audio signal. An analog input is used, not digital.

Well that explains why I just discovered the wired connection works only 1 in 5 attempts. No wired connection should have a failure rate that high. It's getting the digital signal.

I'll try removing the buffer.

Also, I see the schematic for the micromodem transmitter uses 4 digital pins to make a DAC with a mic level output that goes to the radio. I don't think the TX pin on my transmitter is made to take a mic as an input, it wants a DC coupled CMOS logic signal. I've also noticed, only 1 of the 4 pins actually had any signal output, so I've been using that pins digital output. Are there changes I need to make on the transmitter too?

#10

GustavoMcSavy:
Well that explains why I just discovered the wired connection works only 1 in 5 attempts. No wired connection should have a failure rate that high. It's getting the digital signal.

AFSK is usually analog signals changing frequency right? So analog signals would still be coming in through the transmission line. The interpretation of the changing frequency behaviour is where the digitally coded message is meant to be recovered.

#11

Are there changes I need to make on the transmitter too?

The transmitter section of microModem generates a low level audio output, suitable for the MIC input of a transceiver.

If your radio transmitter does not have a MIC input, it is not suitable for use with microModem. No wonder that you are having problems!

#12

Southpark:
I see. Yeah... are you using methods like manchester encoding for synchronisation? I reckon you're really close to getting things working.

I'm not familiar with Manchester encoding, but the library should be taking care of everything that I'm aware of.

Southpark:
AFSK is usually analog signals changing frequency right? So analog signals would still be coming in through the transmission line. The interpretation of the changing frequency behaviour is where the digitally coded message is meant to be recovered.

Yes, but I sent the signal through a wire instead of the radio, so the signals are not coming through the transmission.

jremington:
If your radio transmitter does not have a MIC input, it is not suitable for use with microModem. No wonder that you are having problems!

Ouch, I was afraid of that. Is there any way to make it work with what I have?

#13

From what I have seen so far this project never had a feasibility study or a design review.
It sounds like there is no basis for this project to work.
How exactly did you come up with the current design ?

#14

It sounds like there is no basis for this project to work.

It will work very well, providing the appropriate transmitter and receiver are used appropriately. I have done so and am quite happy with the performance.

#15

raschemmel:
From what I have seen so far this project never had a feasibility study or a design review.
It sounds like there is no basis for this project to work.
How exactly did you come up with the current design ?

I guess I haven't explained my project well enough then.

I'm transmitting GPS locations using APRS radio transmissions. First I looked at a simple circuit called Micromodem. I used this design to make a receiver, which I erroneously added a buffer to. I ran into trouble when I was trying to get the software designed for it onto the arduino. It required a bunch of complicated steps, AVRdude, and a tool kit. I couldn't figure it out, so I found a library called SoftModem that would allow me to use the same frequencies and baud. It was working for the most part, but there were issues correctly interpreting the data on the receiver. I couldn't figure it out, then Jremington showed me the LibAPRS library. Since it was just another arduino library, I could easily study the library files, write some code based on the example, and upload it to the arduino. Within minutes I was able to send APRS packets between two arduinos using a wired connection.

For a connection between the two radios, I figured I could leave out the DAC circuit, and just give the digital signal right to the transmitter. I could only find one of the 4 DAC pins actually doing anything, and on the active one all the signal was present. That's why it worked wired. Then I tried it with the radios, and discovered some issues. That's why I made this post. I later discovered that my wired transmissions weren't working out as good as it appeared at first because I slowed them down and saw that only 1 in 5 were getting through. Now I see that I can't use the library like this so easily.

Complications? Yes. But infeasible? I can't see how, based on how many others have been successful with this library. I'll admit I didn't have it fully planned out, but this isn't a job to me, it's a hobby. I never planned out my lego builds when I was a kid either lol.

The next step is to figure out the difference between the mic input of a normal radio, and the digital input of my radio. Then I will see if I can make adjustments to the code circuit or both to make it compatible.

Transmitter Datasheet: HX1

#16

I think you may in over your head. You are making decisions based on pure conjecture and not electrical design experience. I am not saying you shouldn’t try to do this but I think you should know more about the TYPE of LEGOS you are trying to plug together. At first glance it just strikes me as a sort of electronic fruit salad that’s been half tossed. I would have started with a block diagram in the first post and a simple question “how do I interface these blocks ?”

instead of this:

I’m attempting to transmit data over radio signals, but my receiving end is spitting out gibberish.

The serial monitor shows,
Start
0 0 1 0 0 0 16 5 (@) (!) 0 1 0 0 0 128 16 4 0 17 0 1 0 0 0 0 4 1 0 0
0 0 1 176 2 0 0 4 1 0 0 130 0 0 ( ) (") 0 0 0 0 0 4 1 0 0 1 16 0 (@) 0 0 0 0 4 1 0 0 0 (H) 0
0 0 0
When it should be a legible message.

On the signal out I have a radio transmitter with a Tx pin connected to serial 2 on an Arduino mega. The code just enables the transmitter, then does “Serial2.println(“message”);”. Baud is 1200. Transmitter data sheet here (HX1)

On the receiving end I’m using a library called SoftModem (SoftModem-005) to demodulate the signal. I’m pretty sure my code here is the reason the gibberish, I have almost no idea what I’m doing. Most of this code is from a tutorial I found. These are the settings I have in the .h file.

#define SOFT_MODEM_BAUD_RATE (1200)
#define SOFT_MODEM_LOW_FREQ (1200)
#define SOFT_MODEM_HIGH_FREQ (2200)
#define SOFT_MODEM_RX_BUF_SIZE (32)

There is no schematic attached to your first post. Later you posted this:
radio modem problem.jpg

I don’t see anything here that indicates an AUDIO =>TTL or TTL => AUDIO interface in your system.
Audio signals must be capacitively coupled and voltage biased to 2.5V to interface to an analog input.

I don’t see any oscilloscope screenshots for inputs or outputs. (until later in your most recent posts)

You certainly get an “A” for AMBITION, but I would give lower marks for planning and execution because you are interfacing very different types of circuit blocks.

You probably think I am unfairly critical but that’s because I am a professional electronics engineering technician and these kinds of projects are usually done with a lot more research in the commercial world so seeing this as a “hobby” project, it strikes as just “thrown together”, rather than “carefully planned” and the forum posts strike me as sorely lacking in schematic reference detail.

That’s just my opinion. I’m not saying you shouldn’t try it. I’m just saying you should provide more technical details in the way of schematics, which seem to be completely missing here.

I’m a hardware person and it just seems rather difficult to separate software issues from hardware issues with so little information.

In general, it just seems like you are stumbling around because you are making so many assumptions that are not based on an electrical engineering design background. It is , as you say, just a hobby, so of course you can do whatever you want but I have specifically stayed out of this post because I don’t see any schematics. Had they been attached, I probably would have gotten more involved. Without them, I don’t see any point in even thinking about your problem. I’ve just sharing my viewpoint, which of course you are free to ignore and continue as you have been doing. What’s the worst that can happen anyway ?

#17

I’ve seen the HX1 used in a number of high altitude balloon projects, like this one: APRS Micro-Trak 300 V1.3

Evidently the HX1 has a digital input but the internal modulation generates the required audio tones in the matching receiver, HRX1. So, the microModem tone generation code is not needed. It appears that you still have to assemble packets with preamble, sync, data and checksum.

To use the HX1, you need the matching receiver and to follow the manufacturer’s or other people’s advice on how to set up a functional communications system. I haven’t done the research required in order to be of assistance.

The microModem software is better suited to handheld radios intended for voice communications.

Note that you need a license to operate the HX1.

#18

raschemmel:
I don't see anything here that indicates an AUDIO =>TTL or TTL => AUDIO interface in your system.
Audio signals must be capacitively coupled and voltage biased to 2.5V to interface to an analog input.

The diagram wasn't meant to include everything, it was just to show where I think the two different types of signal modulation are happening, FM and FSK, to make sure I wasn't mixing them up. I do have a capacitively coupled receiver. The schematic was available in the link to the micromedem I said my circuit was based on, but it probably would have been better to post it here too.

raschemmel:
I don't see any oscilloscope screenshots for inputs or outputs. (until later in your most recent posts)

Maybe you missed it, but in the previous posts before the scope shots, I mentioned that I didn't have a scope. I just bought my first oscilloscope and as soon as I learned how to use it I had those pictures up.

raschemmel:
You certainly get an "A" for AMBITION, but I would give lower marks for planning and execution because you are interfacing very different types of circuit blocks.

I have the patience to screw up repeatedly. It's the most effective way for me to learn. It's more about the learning than the project anyway.

raschemmel:
You probably think I am unfairly critical but that's because I am a professional electronics engineering technician and these kinds of projects are usually done with a lot more research in the commercial world so seeing this as a "hobby" project, it strikes as just "thrown together", rather than "carefully planned" and the forum posts strike me as sorely lacking in schematic reference detail.

Screwing around, tossing stuff together that shouldn't fit, inconsistent progress, and dead ends. All part of the amature/hobbiest experience. I am learning, and I'll take your advice to include every last detail, schematic, and line of code of my project when I make the next post.

jremington:
I've seen the HX1 used in a number of high altitude balloon projects, like this one: APRS Micro-Trak 300 V1.3

Evidently the HX1 has a digital input but the internal modulation generates the required audio tones in the matching receiver, HRX1. So, the microModem tone generation code is not needed. It appears that you still have to assemble packets with preamble, sync, data and checksum.

To use the HX1, you need the matching receiver and to follow the manufacturer's or other people's advice on how to set up a functional communications system. I haven't done the research required in order to be of assistance.

The microModem software is better suited to handheld radios intended for voice communications.

So do I need to buy another radio? I was hoping to avoid that. Since all the APRS transmissions should be standardized, would I be able to keep the receiver I have and just change the code on the transmitter to just write all the right bits? The HX1 is made specifically for APRS, and If I can receive any other APRS packet on my micromodem/LibARPS receiver, I should be able to receive the packets from the HX1.

Is there a way to get LibARPS to give me the unparsed APRS packets, like a GPS can return NMEAs as they come?

jremington:
Note that you need a license to operate the HX1.

I got it, they even made me give my call sign before I was allowed to buy it. I'll admit, I only studied for two hours before taking the test. I got almost every answer correct on the test, but it may have been too easy if it lets a dummy like me on the airways.

#19

There is nothing on the HX1 product page or data sheet to indicate that it was "made for APRS" and nothing to suggest that the HX1 is intended for use with receivers other than those made by Radiometrix. APRS is listed as one of several possible applications.

In order to use this transmitter for APRS, one would normally need quite a bit more information than is given in the HX1 data sheet. I'm certainly puzzled about how it is supposed to work!

Update: I looked through the code and schematics of the APRS Trackuino project, which uses the HX1 as the transmitter. Trackuino: Trackuino Shield

As you will see, the TX input on the HX1 is analog 0-5V, and the 1200/2200 Hz AFSK modulation of the HX1 carrier is generated by the Arduino using fast (62.5 kHz) PWM. I'm surprised that no low-pass filter is used between the MCU and the HX1 input. The Trackuino software is quite a sophisticated package.

The microModem TX output isn't directly compatible with the HX1. With an amplification stage, the combination might be made to work.

#20

jremington:
There is nothing on the HX1 product page or data sheet to indicate that it was "made for APRS" and nothing to suggest that the HX1 is intended for use with receivers other than those made by Radiometrix.

APRS is listed as one of several possible applications.

In order to use this transmitter for APRS, one would normally need quite a bit more information than is given in the HX1 data sheet. I'm certainly puzzled about how it is supposed to work!

I was a bit confused by the lack of information on the datasheet as well. I didn't even know it would produce the two tones on it's own until you pointed that out. That's why I was trying to feed it an already modulated signal. Modulation is probably the wrong word for using tones to represent bites, but i think you get what I mean. I saw that comment before you edited it, I'm not that dumb, but it might appear that way because I'm pretty bad at communicating my thoughts. English is not my strongest subject but I'm only 19, so I have time to work on it.

I'm just going to think out loud about this for a bit. The HX1 is available in multiple frequencies, so the list of other applications may be referring to other frequency models. Since 144.39MHz is reserved for APRS in the US it shouldn't be used for other things. If it's producing the two tones on its own, it must be the standard 1200 and 2200 then. It did mention in the datasheet that it can send data up to 10kbps [Edit: 3kbps]. That tells me the baud is variable, so either data in is limiting the baud, or there's a way to tell the transmitter what baud I want to use. If there's a set of commands I can send to it, it certainly did a bad job of informing me on the datasheet. My impression is that this is a dumb transmitter. It's just going to take a signal in, and emit FM. Unlike what I would call a smart transmitter, that I can send commands to set baud/tone frequencies. I'm going to do some experiments. Write a byte to the transmitter, and see what it looks like on the receiver. I'll look for the two tones and the baud rate on the receiver and compare it to the signal going into the transmitter.

I'll get back on here when I figure out how this transmitter is supposed to work.