Packet Radio Device needs Something...

Alex Bell

Hi Forum Folk: Thanks for all your clues last week, but I am still having troubles with my code. My listing 1200 TX is a familiar program from the SX books with a few twists. I have a series of Bytes hard-coded in the program which are called by send_byte in a routine that generates a 1200 baud data burst in the familiar UART transmitter. I send it as a packet burst with the flag $AA etc. It is sent out of eprom MSB first. This program works. But since I don't want to hard-code my message everytime I want to send a different message, I thought I could use the UART transmitter-receiver code and ship in my "short message" via the async receiver, and then echo it back out, but first, rearrange the byte MSB first and clip off the start/stop bits. In essence it is an async to packet-burst transmitter. Hooked to a radio modem, it would be a short message paging system or Ham packet beacon. However, the code 1200TXRX receives the string from the BS2, (and displays it in circular memory in the Debug window, in the correct order {I guess!} but then the creature that is shifted in the transmit routine bears no family resemblance to what came in the receive routine...neither does it "look like" the reverse of the incoming string, either!
It is as if the fundamental nature of how memory works between the two codings is different...I am using a digital storage scope to look at the outputs, the BS2 is sending data out its pin 15 in a serout, 15,813 [noparse][[/noparse]$AA,$B4,$33] command right into rb.2. The first coding displays on my "packet receiver" as it should (the hard-coded message) but the RS-232 to Packet does not? I have gone over and over the results but can't figure out how it is getting garbled. Maybe you can...thanks! Alex Bell

mojorizing

Hi Alex,
Sounds like a cool project. I looked over your 1200TX and I noticed a few things you might want to change.

Firstly, with the code:

send_byte  bank  serial

:wait    test tx_count    ;wait for not busy
     jnz :wait
    
    mov    tx_high, w
    mov     tx_count, #8  ; 8 data
    ret

you want to save the message then wait due to the fact that W will change as you wait.

send_byte  bank  serial

          mov    tx_high, w
      mov     tx_count, #8  ; 8 data

:wait    test tx_count    ;wait for not busy
      jnz :wait
    
    ret

Secondly, I don't believe your txdivisor is correct. That variable is to load tx_divide with a flag equal to 2^baud_bit as is refered to in Gunther Daubach's book.

What osc are you using in your hardware?

You mentioned that this 1200TX code works but I'd like to know what you think on these two points.

Yhanks, Kevin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 kinds of people in the world.... those that know binary, and those that don't.

Alex Bell

Thank you Kevin, I am waiting for work to end so I can go home and make the adjustments you suggest. I don't remember if the original code is from Al William's or Guenther's book, but basically I started with the program (12.2) listing that takes in a serial stream and changes the small letters to capital letters and echoes them back out. I first rearranged the baud rate because this peculiar packet operation runs at 1200 baud, even though "modern" amateur packet is running at 9600 and probably above...I kept changing values down from 9600 but as I approached 1200 baud (using the 50 MHZ crystal) my divisor approached the limit of /255 so the only choice I had was to reduce the frequency. I had available some 11.0592 Mhz crystals from my work with Intel 8052 Basic processors, and thus the different divisor rates, etc. The 11.0592 Xtals are used to develop even divisible baud rates in the Intel chip. The rates in my listing appear to work, I am able to run any of the programs in the books. and echo the serial stream at 1200 baud on a pc.
I usually like to design my own hardware. But in this case I am using someone else's equipment and I have to make myself conform to the 1200 baud and MSB first of the original designer! It is good discipline!
The serial stream that comes out of TX-RX version of the code loads properly into RAM ( I guess) but does not transmit correctly, and the characters output, when written down, seem to be offset by a few bits: my 1010 flag for example, can come out as 0101, so it may be that the ram writing out acts differently than the hard-code eeprom (first) example. I have also heard about "zero terminated strings" but I am a Telephone guy... I don't know what that means yet. I was thinking maybe RAM doesn't have them, but EEPROM does?
I will try your suggestion and report back. I know these assembly routines are not easy, but I believe if I keep on pluggin' and chuggin' eventually it will yield. Thank you for your help! Alex