Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Software controlled radio project with PIC

Status
Not open for further replies.
Hi, Here's another example of the problem:
Minicom, screen, PuTTY, and various other terminal clients were giving me a very rough time with these units. The initial handshake command is “AT+DMOCONNECT” with the carriage return and line feed characters. With the terminal programs I listed above, each character was individually sent, and I was commonly seeing “+DMOERROR” as I was trying to type out AT+DMOCONNECT. Python was the tool that finally worked.

import serial
ser = serial.Serial(‘/dev/ttyAMA0’, 9600, timeout=2)
ser.write(‘AT+DMOCONNECT\r\n’)
ser.readline()
C.
 
OK this is not spam, but after reading this thread I felt that the OP may benefit from what I'm about to put out a shameless plug on based on my own personal experience with the product.

Another radio you may want to check out are the Synapse Wireless RF Engine products. Their RF series radios being the most popular, they operate at 2.4GHz and mesh network with other Synapse radios by default. They have their own onboard operating system called SNAP OS (Synapse Network Application Protocol) and you can write user scripts for each SNAP device using a programming language known as SNAPpy, which is a subset of the Python programming language. They also support OTAP (Over The Air Programming) of user scripts.

Each SNAP device (i.e. a Synapse radio that runs the SNAP OS), just like a microcontroller, has several GPIO pins, two UARTs, SPI, I2C, PWM, and several other peripherals on chip. You can either tie them to a host processor or use them completely stand alone.

Another neat feature of them is that Synapse has a Python library called SNAP Connect available for them. It allows you to write user scripts for your PC in Python just as you would for a Synapse radio, turning your PC into another SNAP device on the network. This makes possible IoT applications and you can access your SNAP wireless network from anywhere there is an internet connection.

Check them out at https://www.synapsewireless.com
 
HiJ,
Interesting stuff there thanks. Do you program in Basic? I particularly want to use the DRA818U frequency range.
C.
 
Hi,
What's wrong?
I've set-up an 18F2431 with LCD and LED on a breadboard (not my favourite things). Here's the test program: It's not working, so no LED test flash at the beginning and nothing on the LCD. It simulates ok. I'll recheck the circuit.
C.
 

Attachments

  • 18F2431 INT20 DRA818U TEST 060916 1100.txt
    3.2 KB · Views: 350
hi C,
you have this header:

Define CONFIG1L = 0x00
Define CONFIG1H = 0x08 'Int osc
Define CONFIG2L = 0x1e
Define CONFIG2H = 0x00
Define CONFIG3L = 0x00
Define CONFIG3H = 0x83
Define CONFIG4L = 0x80 'HVP
Define CONFIG4H = 0x00
Define CONFIG5L = 0x0f
Define CONFIG5H = 0xc0
Define CONFIG6L = 0x0f
Define CONFIG6H = 0xe0
Define CONFIG7L = 0x0f
Define CONFIG7H = 0x40

'18F2431 INT8 DRA818U TEST 060916 1100
Define SIMULATION_WAITMS_VALUE = 1
Define CLOCK_FREQUENCY = 8
AllDigital

Then you have:
OSCCON = %01111100 '20MHz the internal osc is set to OFF

Which clock freq and source are you using.?

Also this message is wrong.
setgroupstr = "AT+DMOCONNECT <CR><LF>" 'Initial value of the string

It should be:
setgroupstr = "AT+DMOCONNECT" + crlf 'Initial value of the string

E
 
Hi Eric,
Aha!
I got mixed up copying from your 18F4520 20MHz prog:confused:
I want to use the fastest internal oscillator as poss on the 18F2431, I think it's 8MHz?
I'll change OSCCON to OSCCON = %01111110 '8MHz

I copied and pasted the AT+DMOCONNECT <CR><LF> from the data sheet, I am puzzled about the <>, and the correct sending format. I've seen so many variationswhile looking for what the problem is, the latest being: "ATATAT"+Chr$(13)+Chr$(10) and "ATATAT"+Chr$(13)+Chr$(10) which both produce the usual +DMOERROR, when using terminals.
Let's hope the problem is with the mode that the message is sent.
Thanks, C.
 
hi C.
"ATATAT"+Chr$(13)+Chr$(10) and
"ATATAT"+Chr$(13)+Chr$(10) which both

These two are the same.?
E
 
hi C.
"ATATAT"+Chr$(13)+Chr$(10) and
"ATATAT"+Chr$(13)+Chr$(10) which both

These two are the same.?
E
Hi E,
It should have been:
"ATDMCONNECT"+Chr$(13)+Chr$(10) and
"ATATAT"+Chr$(13)+Chr$(10)
My computer went wonky, and would allow me to edit, so I turned it off.
They were suggestions, but I think the proper commands are as we had them, AT+DMOCONNECT <CR><LF>, with perhaps changes like CD LF and no <>, as the data sheet states ASCII.
C
 
Hi E,
It should have been:
"ATDMCONNECT"+Chr$(13)+Chr$(10) and
"ATATAT"+Chr$(13)+Chr$(10)
My computer went wonky, and would allow me to edit, so I turned it off.
They were suggestions, but I think the proper commands are as we had them, AT+DMOCONNECT <CR><LF>, with perhaps changes like CD LF and no <>, as the data sheet states ASCII.
C
You mean "AT+DMCONNECT"+chr(13)+chr(10) ??
That would seem to be the correct format based on earlier posts.
Any text on the web (or manuals) that shows <CR> or <LF> means those are to be replaced with their binary equivalent, like chr$(13) and so on. Some terminal emulators just send <CR>, some send both. Some send neither unless instructed to do so. Oshonsoft compiler has a directive called CrLf, which inserts those binary values as a string. So, your string could read:
"AT+DMCONNECT"+CrLf
as Eric shows.

EDIT: BUG in Oshonsoft concatenating strings on standard pic compiler for 16F690 (not tested on PIC16 or PIC18)!
Camerart, you may be a victim of a faulty compiler concatenating strings...
I was playing around with the +chr(13) type of strings, and the compiler seems to mess up when concatenating on one line. For example, making a string and adding "CrLf" seems to be ok. However, setting a string and adding +chr(13)+chr(10) corrupts the string!
Below is sample code I ran in SIM, and set watch variables.

Dim i1 As Byte
Dim i2 As Byte
Dim i3 As Byte
Dim i4 As Byte
Dim j As String


j = "A" + CrLf
'Above works ok, get 3 byte string A plus CR and LF
i1 = Asc(MidStr(j, 1, 1))
i2 = Asc(MidStr(j, 2, 1))
i3 = Asc(MidStr(j, 3, 1))
i4 = Asc(MidStr(j, 4, 1))

j = "" 'Clear (not necessary, makes no difference)

j = "A" + Chr(13) + Chr(10)
i1 = Asc(MidStr(j, 1, 1))
i2 = Asc(MidStr(j, 2, 1))
i3 = Asc(MidStr(j, 3, 1))
i4 = Asc(MidStr(j, 4, 1))
'Above messes up, puts in double A and chr(10) !!

j = "A"
j = j + Chr(13)
j = j + Chr(10)
'Above concatenation, one at a time, works ok

i1 = Asc(MidStr(j, 1, 1))
i2 = Asc(MidStr(j, 2, 1))
i3 = Asc(MidStr(j, 3, 1))
i4 = Asc(MidStr(j, 4, 1))
 
Last edited:
Hi,
S, it will take me some time to understand better your concatenation, information, but I'm sure you're on the right lines. So far I've only tried Terminals (Putty and Teraterm) one contributor was using Arduino. I'm sure there are settings in each of them to output what's needed.

Anyway I got the 18F2431 working for the fist time, and SUCCESS:) using the 'latest' test program, it now sends "AT+DMOCONNECT" + CrLf (BLUE) and +DMOCONNECT:0 which is 'accepted'.

Having said that, it's a right mess on a breadboard and needs prodding to get it to work, so needs a new soldered circuit for stability.

Thanks, C.
 
Ok C.
My point was there there seems to be a bug in the Oshonsoft compiler when doing certain string concatenations all on one line. It definitely screwed up when I added "+ chr(13) + chr(10)" to a string of a single letter. Hopefully others can try the code I posted to confirm they too see that bug, so it is not just me...

Glad you got the communications going, at least the basic start of it.
 
Ok C.
My point was there there seems to be a bug in the Oshonsoft compiler when doing certain string concatenations all on one line. It definitely screwed up when I added "+ chr(13) + chr(10)" to a string of a single letter. Hopefully others can try the code I posted to confirm they too see that bug, so it is not just me...

Glad you got the communications going, at least the basic start of it.
Hi S,
I don't have much idea what your asking, but I stepped through you code set to 18F2431 and saved the variables at each J so the last set is at the bottom, if you follow.
If you want another test, you will have to exlain letter by letter, or make a separate posting. Perhaps someone else understands and gives better results:)
C
 

Attachments

  • SAGOR.txt
    369 bytes · Views: 264
Your 3rd batch of results show the same as I got, the string has two "A" in it instead of one as expected. First two results are correct, third is corrupted, last is correct..
The issue is, the Oshonsoft compiler has a bug when using code like that to produce the third result.... One cannot concatenate multiple strings in one line of code.
i1 to i4 are just variables to extract the string values for debug purposes - to set "watch variables" in the SIM to see what the string characters actually are....
 
Hi,
I contacted the complete radio designer see #1 and told him about my terminal woes, he said he uses Termite 3.1, so I tried it and here's the successful result.
C.
 

Attachments

  • Termite.jpg
    Termite.jpg
    180.6 KB · Views: 306
Hi,
My idea for a minimum transmitter, for sending data back to base e,g, security etc, wasn't a good idea, as I was hoping to use the module without a PIC to control it, but it would rely on the PTT/TX being on all of the time, and this is not good, so I have to go back to programming the 18F2431. If I can figure out Eric's 18F4520 prog and the SCR one on post #1 and combine them.
Still trying to be minimum, I hope to get away without the LCD, and use buttons, menus and LEDS for frequency changes.
As usual I'll up date everything on POST#1
C.
 
Hi,
After many hours testing and researching the DRA818U module, I've come to the conclusion that they don't send and receive data, but only voice.

I'm now looking into other modules. I've so far been using RFM22 modules on the OrangeRx units, which are programmed using a Chrome app. I want to be able to write my own programs if I can.

There is another interesting module RFM96W which looks good, but uses the LoRa system, that I don't know much about, so will need a lot of help with them.

C.
 
Hi,
I am switching to RFM modules, away from the DRA818, because the 818 is only for voice, and I want to transmit data, so I'll leave the information here and start another thread.

DATA transmission/receiving using Radio modules.

Cheers, Camerart.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top