HSERIN dropping bits

Geep

New Member
Picaxe 28X2 module, high speed serial port set to 19200, using SETFREQ EM64, HERSETUP B19200_64, with the module's external regulator to get the baudrate I need. I'm working on a two way ham radio project involving a Harris M7100 VHF mobile. I can send a command to the radio to change the system/group, i.e. send the radio to a new channel, and that command with HSEROUT is working nicely. I need to read a memory location in the radio to obtain the SG number, and I can do that with a DISP command in a terminal window to get the radio memory location contents, using HSEROUT and the command. But using HSERIN,0,40 to get enough bytes to extract the 5 bytes that I need, the data returned is not consistent. One run of the test program gets the correct bytes, the next one returns one less location, the next one a different set of numbers. One out of three or four tries returns the correct memory bytes for the system/group I am on. Watching the radio output in a separate monitor window, it is sending the correct data each time, so I have to guess that the Picaxe 28X2 is dropping or adding data at the high speed serial port. I'm monitoring the module information in the monitor window, using SERTXD statements to send the scratchpad memory and RAM so I can monitor. Any thoughts on why the data being returned with the HSERIN command is not consistent? I can't make my channel move verification routine work if the data isn't consistent. Thank you.
 

hippy

Technical Support
Staff member
It could be that the radio is sending data sooner than the HSERIN is ready to receive them. This could cause characters to be lost, things to get out of sync. That it's not consistent could be to do with how quickly the radio responds or what data it responds with.

One way around a problem like this would be to use background receive so the PICAXE is ready to receive data into scratchpad, even before the command to send data is sent.
 

inglewoodpete

Senior Member
It could be that the radio is sending data sooner than the HSERIN is ready to receive them. This could cause characters to be lost, things to get out of sync. That it's not consistent could be to do with how quickly the radio responds or what data it responds with.

One way around a problem like this would be to use background receive so the PICAXE is ready to receive data into scratchpad, even before the command to send data is sent.
Using SerTxd while receiving serial data in the hardware UART can be problematic, although I'd expect you to "miss" entire bytes/characters, rather than individual bits. The reason is that the SerTxd command does not use a hardware UART: instead, it uses software 'bit-banging'. To maintain the strict timing for bit-banged serial output, the PICAXE firmware must ignore all other interrupts while sending data with the SerTxd command.

I have used background serial receive in PICAXE X2 chips reliably at 76,800 baud and reasonably reliably at 115,200 baud.

As hippy suggests, I'd use the 28X2's background receive capability AND ensure any foreground commands that require strict timing are only used when incoming serial data has been received and buffered.
 
Last edited:

Geep

New Member
Thanks for the replies. I tried to use background receipt of data, and nothing appeared with the serial out command. I'll try it again. And I am not running the SERTXD routine when the HSERIN routine is running, only after it has captured the incoming data stream to scratchpad memory, so they are not competing. At least I don' think they are. And my title is misleading, I am missing bytes of data or having bytes added, not bits. I can try running the full program with no serial out debugging and see if I can read the channel number consistently. I guess there isn't any way to debug the program on chip step by step, at least I haven't found one. Not easy to see what's going wrong without having some sort of output from the running program.
 

lbenson

Senior Member
I tried to use background receipt of data, and nothing appeared with the serial out command.
Post your code. If set up properly with HSERSETUP, serial background receive does work, as IP indicates--but different devices work differently, so YMMV.
 

hippy

Technical Support
Staff member
I would suggest trying with something like below to see what results you get, adjusting HSERSETUP polarity if required, and sending whatever "DISP",CR,LF should actually be.

I would use the 8MHz default to start with see how that goes -
Code:
#Picaxe 28X2
#Terminal 9600
#No_Data

PowerOnReset:
  HSerSetup B19200_8, %001 ; <-- May need editing, keep the _8
  Pause 2000
  SerTxd( "Started", CR, LF )

MainLoop:
  Do
    HSerOut 0, ( "DISP", CR, LF ) ; <-- May need editing
    Pause 2000
    Do While ptr <> hSerPtr
       b0 = @ptrInc
       b1 = b0 / $10 + "0" : If b1 > "9" Then : b1 = b1 + 7 : End If
       b2 = b0 & $0F + "0" : If b2 > "9" Then : b2 = b2 + 7 : End If
       SerTxd( "$",b1,b2, TAB, #b0, TAB, b0, CR, LF )
    Loop
    SerTxd( "---", CR, LF )
  Loop
 

Geep

New Member
Thank you for the code snippet. I've tried it, and it does consistently read the radio memory location, both at the 8 Mhz rate and the 64 Mhz set with the external resonator, into scratchpad memory. However, getting the data out of scratchpad memory into RAM glitches about every 7 or 8 iterations of the loop. Restarting the chip restores the reads and they go for a while before glitching. The data written to the scratchpad locations is consistent, so whatever I am doing wrong comes when I read the scratchpad locations into RAM to do a compare with a lookup table. Perhaps I need to be just doing the compare from scratchpad memory against the table memory, rather than writing both sequences back to RAM and then doing the compare. I have Christmas company and have to work tomorrow, so will get into it again on Tuesday and try to post my program for comments and critiques. Thank you all for helping. BTW what does the #NO_DATA directive do?
 

hippy

Technical Support
Staff member
However, getting the data out of scratchpad memory into RAM glitches about every 7 or 8 iterations of the loop.
The Scratchpad is used as a circular buffer when background receive so it could be that you aren't tracking data packets placed in the buffer accurately, or are just reading a fixed location, and that eventually gets corrupted as the buffer fills and wraps back round.

It can sometimes be tricky working with Scratchpad but issues can usually be resolved.

An easy option for what you are doing, sending a command, getting a reply, may be to simply put a "hSerPtr = 0 : ptr = 0" line before your HSEROUT. Then your returned data should always be in the same place, Scratchpad location zero upwards.

The PAUSE 2000 we currently have will ensure the data has been received before processing it but that can be improved upon to maximise the speed of operation. Get it working then optimise is usually the best course.

Posting your code would be great and, if you have a link to a datasheet of the M7100, or can detail what the data returned is and what you need to extract, will also help.

The #NO_DATA directive prevents downloading the Data Eeprom to the chip which slightly speeds up download when DATA commands are not used.
 

Geep

New Member
After a lot of experimenting with timing, my routine is now working. I found that without a substantial pause after the HSEROUT("DISP MEMORY") command to the radio, apparently there was enough discrepancy before the data returned that bytes were dropping. I finally got it down to usually seeing the 93 data bytes that the radio was sending, but every once it a while it would glitch and only see 92, which, of course, displaced the memory compare routine and caused a fail. My solution was to put the display memory request command in a do while loop and only allow it to continue when the correct number of bytes were captured. It's now been running for 20 minutes without a glitch! In the real world, it won't do a channel change until the repeater system controller sets 4 logic outputs to 1's and 0's to represent the binary channel select for the 16 radio channels on command from a user with touchtones. Until the fifth bit get's set, the Picaxe will loop awaiting that event. Now I have to finish up the board that will plug into the repeater station that is the heart of the system, test, and it should work! As a beginner with Picaxe, I appreciate all the help and support, and I have learned a great deal about how to make things work. Once I get it all together and working, I'll post the code and see what I could have done more easily or better from your comments. Merry Christmas all!
 
Top