Rayax 998
- Thread starter julianE
- Start date
inglewoodpete
Senior Member
When I put Rayex998 into Google it came up blank (I have no idea what you are referring to). It will help others to help you if you include a link to the manufacturer's data on the product.
The factory settings put the baud rate at 115200, so you might need a faster chip to send the first AT commands to slow it down enough for a picaxe.
You'll need to run a picaxe on 3.3V or use a voltage adapter.
Putting two modules too close together can damage them. I don't know exactly how close but I'd keep them a few metres apart.
You'll need to run a picaxe on 3.3V or use a voltage adapter.
Putting two modules too close together can damage them. I don't know exactly how close but I'd keep them a few metres apart.
Hi,
It's quite possible for PICaxe's HSEROUT to send single "characters" at 115,200 Baud, the only issue is if the receiving chip will tolerate significant inter-character gaps. Not tested, but since it appears that you only need to send one string of, for example, AT+IPR=9600 , a dedicated HSEROUT 0,("AT+IPR=9600") or at worst a linear string of POKESFR TXREG , "A" : POKESFR TXREG ,"T" : ... etc. (where TXREG = $7A) should be sufficient, probably with a SETFREQ of M16 or M32 .
But interestingly, the Data Sheet appears to show an "Idle Low" serial protocol, which is the original RS232 Polarity, (as used by PICaxe) rather than the more normal (inverted) "RS232-TTL" polarity (when a "MAX232" type interface chip is not used). Of course either Polarity probably needs the Levels limited to 3.3 volts. PICaxe has no problems Transmitting either Polarity of signal, but sadly a "mistake" in the (M2) base PIC hardware design prevents the Reception of High-Speed Idle-Low RS232 signals (i.e. using HSERIN style commands), so an input inverter may be required
, (which might also give some degree of input over-voltage protection).
Cheers, Alan.
Yes indeed, particularly if you're going to mis-spell REYAX as RAYEX.
It's quite possible for PICaxe's HSEROUT to send single "characters" at 115,200 Baud, the only issue is if the receiving chip will tolerate significant inter-character gaps. Not tested, but since it appears that you only need to send one string of, for example, AT+IPR=9600 , a dedicated HSEROUT 0,("AT+IPR=9600") or at worst a linear string of POKESFR TXREG , "A" : POKESFR TXREG ,"T" : ... etc. (where TXREG = $7A) should be sufficient, probably with a SETFREQ of M16 or M32 .
But interestingly, the Data Sheet appears to show an "Idle Low" serial protocol, which is the original RS232 Polarity, (as used by PICaxe) rather than the more normal (inverted) "RS232-TTL" polarity (when a "MAX232" type interface chip is not used). Of course either Polarity probably needs the Levels limited to 3.3 volts. PICaxe has no problems Transmitting either Polarity of signal, but sadly a "mistake" in the (M2) base PIC hardware design prevents the Reception of High-Speed Idle-Low RS232 signals (i.e. using HSERIN style commands), so an input inverter may be required
, (which might also give some degree of input over-voltage protection).Cheers, Alan.
Last edited:
Thanks Gents. Sorry for my terrible posting, all the years of idleness has made me careless.
I have the module hooked up to my PC using an FTDI cable and have been playing with the AT command set. The baud rate can be set lower, I'll probably use it at 9600. Looks like an easy module to interface to the Picaxe. I'll start working on it this week and probably have questions along the way.
here is the Link to the product, plenty of tutorials for use with 'duino.
terribly sorry for the poor opening post. all the very best.
I have the module hooked up to my PC using an FTDI cable and have been playing with the AT command set. The baud rate can be set lower, I'll probably use it at 9600. Looks like an easy module to interface to the Picaxe. I'll start working on it this week and probably have questions along the way.
here is the Link to the product, plenty of tutorials for use with 'duino.
terribly sorry for the poor opening post. all the very best.
fixed the mis-spell.Hi,
Yes indeed, particularly if you're going to mis-spell REYAX as RAYEX.
It's quite possible for PICaxe's HSEROUT to send single "characters" at 115,200 Baud, the only issue is if the receiving chip will tolerate significant inter-character gaps. Not tested, but since it appears that you only need to send one string of, for example, AT+IPR=9600 , a dedicated HSEROUT 0,("AT+IPR=9600") or at worst a linear string of POKESFR TXREG , "A" : POKESFR TXREG ,"T" : ... etc. (where TXREG = $7A) should be sufficient, probably with a SETFREQ of M16 or M32 .
But interestingly, the Data Sheet appears to show an "Idle Low" serial protocol, which is the original RS232 Polarity, (as used by PICaxe) rather than the more normal (inverted) "RS232-TTL" polarity (when a "MAX232" type interface chip is not used). Of course either Polarity probably needs the Levels limited to 3.3 volts. PICaxe has no problems Transmitting either Polarity of signal, but sadly a "mistake" in the (M2) base PIC hardware design prevents the Reception of High-Speed Idle-Low RS232 signals (i.e. using HSERIN style commands), so an input inverter may be required
Cheers, Alan.
Well, I had some success today. I'm using a PC on the transmit side and a picaxe 08M2 on the receive side. Using simple serin C.1, T9600_8,B12,B13
I am getting data when i transmit 2 characters. The data is consistent but does not correspond to what i'm sending.
I'm thinking next step is to try it with arduino and also try an inverter circuit. I'm fairly sure it can be made to work with a picaxe.
I am powering everything with 3.3V.
I am getting data when i transmit 2 characters. The data is consistent but does not correspond to what i'm sending.
I'm thinking next step is to try it with arduino and also try an inverter circuit. I'm fairly sure it can be made to work with a picaxe.
I am powering everything with 3.3V.
Another wrinkle found, there is a preamble before the payload message is delivered, when the serial stream comes in the module outputs +RCV=
and then a couple more numbers separated by commas and finally the payload message. I have been able to receive the +RCV part ascii characters consistently but the data after isn't always the same. I have a lot more reading to do on receiving serial particularly the HSERIN command. I also have another FTDI cable ordered so i can attach a laptop to the receiving module and capture the serial data on a terminal.
and then a couple more numbers separated by commas and finally the payload message. I have been able to receive the +RCV part ascii characters consistently but the data after isn't always the same. I have a lot more reading to do on receiving serial particularly the HSERIN command. I also have another FTDI cable ordered so i can attach a laptop to the receiving module and capture the serial data on a terminal.
Hi,
Much will depend on the length of the inter-character gap (if any) that the Reyax998 delivers in its responses. Short gaps may require the "HSERIN" (hardware) to be used, but there may be issues with the HSERIN command. IMHO HSERIN with the M2 chips has a major "bug" and the best solution is to use (two) PEEKSFR commands instead. The whole story starts in This Long Thread but when you get the gist of the problems then perhaps jump on to posts 18 or 21 and 28 onwards.
Cheers, Alan.
Much will depend on the length of the inter-character gap (if any) that the Reyax998 delivers in its responses. Short gaps may require the "HSERIN" (hardware) to be used, but there may be issues with the HSERIN command. IMHO HSERIN with the M2 chips has a major "bug" and the best solution is to use (two) PEEKSFR commands instead. The whole story starts in This Long Thread but when you get the gist of the problems then perhaps jump on to posts 18 or 21 and 28 onwards.
Cheers, Alan.
Nially
That would have been my first step. Program an emitter to send 1 to 10 in a loop and power it off a couple of 1.5V batteries. Then program a receiver to catch what the emitter sends and show it in the terminal. Then, lower the baud rates to something a 08M2 is comfortable with and try it on Picaxes.
Here, Picaxe "foibles" are getting in the way.
I have it working reliably at 4800 baud.
I'm sending using the PC Terminal with an FTDI cable,
AT+SEND=2,3,ABC
The 2 after the equal sign is the ADDRESS of the module that's attached to the picaxe.
The 3 is the size of the payload
ABC is the payload
And here is the simple working code.
and here is the terminal output,
+,R,C,V,=,3,,,3,,,A,B,C
the preamble is +RCV and I forget what the 3, 3 is, might be signal strength.
I'm guessing I should be using BPTR to store the values, this was the simplest I could make it.
I can use some help with HSERIN command and anything else that you'd like me to try.
Next step is to send the AT+SEND=2,3,ABC command using picaxe.
I'll be doing a range check as well, supposed to work for several kilometers.
I'm sending using the PC Terminal with an FTDI cable,
AT+SEND=2,3,ABC
The 2 after the equal sign is the ADDRESS of the module that's attached to the picaxe.
The 3 is the size of the payload
ABC is the payload
And here is the simple working code.
Code:
#picaxe 08M2
setfreq m8
pause 2000
LOW C.1
Sertxd ("start", cr, lf)
DO
serin C.1,T4800_8,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12
Sertxd (B1,",",b2,",",b3,",",b4,",",b5,",",b6,",",b7,",",b8,",",b9,",",b10,",",b11,",",b12, cr, lf)
loopand here is the terminal output,
+,R,C,V,=,3,,,3,,,A,B,C
the preamble is +RCV and I forget what the 3, 3 is, might be signal strength.
I'm guessing I should be using BPTR to store the values, this was the simplest I could make it.
I can use some help with HSERIN command and anything else that you'd like me to try.
Next step is to send the AT+SEND=2,3,ABC command using picaxe.
I'll be doing a range check as well, supposed to work for several kilometers.
Hi,
It's interesting that you're using a T4800 baud setup (i.e. "True", "TTL" or Idle-High) which is what I would have expected, except that page 3 of the Reyax Data Sheet (linked in #3) shows an Idle-Low waveform with the specific statements : "Keep Low before power on / off". That might be intended to prevent "Phantom Powering" and strictly there should be a HIGH C.1 at the start of the program to set the correct Idle level. But how could the program "know" when a Power OFF might occur, to activate a LOW C.1 ?
There seems to be quite an "overhead" with the number of (non-data) characters transmitted and received (which might suggest why the default baud rate is set as high as 115k baud). But I believe that LoRa is much more aimed at Long Range communications rather than a High Data Rate. It would be interesting to know the time gaps between characters at both 4800 baud and at a/the higher rate. If you don't have a 'Scope or Logic Analyser, then the PICaxe might be programmed to estimate the time entirely by software. I had hoped to post a simple test program to do this (and emulate HSERIN), but it's quite complicated because the SERIN command contains a (unknown variable delay) loop that waits for the arrival of the next Start Pulse(s). Thus a program cannot easily make a direct measurement between the end of a Stop Pulse and the beginning of the next Start Pulse.
________
The HSERIN command (with M2 chips) is very different to the SERIN command. First, it cannot receive multiple bytes and it generally returns a single Word variable so it cannot directly use the @BPTR variable, let alone @BPTRINC which may exhibit some "unexpected behaviour" (aka a Bug). Furthermore, the command doesn't (wait to) "receive" a Serial Data byte, it only examines the (on-chip) Hardware Receive Buffer which might (or might not) contain a previously-received "valid" data byte. Generally, the High Byte of the returned word is used to determine IF the Low Byte contains a valid data Byte that the program can process. But if not all of the potential 256 received byte values are "possible", then one of these can be used as the marker instead.
The above is a four-stage process in a Basic Program: i.e. : Pre-Load a "marker" byte/word > Use HSERIN to "Update" the Byte/Word > Check if the marker has been changed (overwritten) > If so, extract the data byte. This seems no faster than working directly with the Hardware Receive Register(s) via two PEEKSFR commands, i.e. : Read the buffer flags (byte) > Has a (new) byte been received? > If so, then Read the received byte from the buffer. And that is before we consider a potential "Bug" in the HSERIN command :
The "Base PIC's" Serial Receive Buffer can store only two Bytes and if a third arrives before the first has been Read (by the Program) then this last byte is "lost" and the hardware (intentionally) locks up until it is Reset. This is a "fatal" error because at least one byte has been lost and probably more whilst the error is detected and the relevant Hardware is reset. This obviously sets an upper limit to the rate that complete characters can be received (and processed), but much higher baud rates are still possible, provided that there are sufficiently long gaps between the characters. The problem (Bug) with the HSERIN command is that sometimes it "thinks" that an overrun has occurred, even when it hasn't. Thus it Resets the hardware, effectively corrupting the subsequent character(s), if they follow closely after the previous one.
A few years ago I devised an alternative to HSERIN, which could reliably receive at up to 4,800 baud with a 4 MHz clock (equivalent to 38,400 baud at 32 MHz), of "concatonated" (i.e. adjoining) characters, and optionally interrupt-driven. However, looking back at that program code now, perhaps it was too "ambitious" for general purpose use, because code with an upper limit of 2,400 baud at 4 MHz (i.e. still up to 19,200 at 32 MHz) should be much easier to use and understand. I'll take another look at those programs to see if I can offer something suitable to receive High(er) baud rates (than SERIN) and to optionally measure the inter-character gap times.
Cheers, Alan.
Yes, it's much better to receive the data via a string of @BPTRINC variables. Personally, I reserve all the single-digit variables (i.e. up to b9) for "global" or general purpose use, so would initialise BPTR to 10, but it could be set to 28 (or even higher) to leave all the regular variables for general usage. Even an 08M2 has RAM up to byte 127 (and the other M2s up to 511).
It's interesting that you're using a T4800 baud setup (i.e. "True", "TTL" or Idle-High) which is what I would have expected, except that page 3 of the Reyax Data Sheet (linked in #3) shows an Idle-Low waveform with the specific statements : "Keep Low before power on / off". That might be intended to prevent "Phantom Powering" and strictly there should be a HIGH C.1 at the start of the program to set the correct Idle level. But how could the program "know" when a Power OFF might occur, to activate a LOW C.1 ?
There seems to be quite an "overhead" with the number of (non-data) characters transmitted and received (which might suggest why the default baud rate is set as high as 115k baud). But I believe that LoRa is much more aimed at Long Range communications rather than a High Data Rate. It would be interesting to know the time gaps between characters at both 4800 baud and at a/the higher rate. If you don't have a 'Scope or Logic Analyser, then the PICaxe might be programmed to estimate the time entirely by software. I had hoped to post a simple test program to do this (and emulate HSERIN), but it's quite complicated because the SERIN command contains a (unknown variable delay) loop that waits for the arrival of the next Start Pulse(s). Thus a program cannot easily make a direct measurement between the end of a Stop Pulse and the beginning of the next Start Pulse.
________
The HSERIN command (with M2 chips) is very different to the SERIN command. First, it cannot receive multiple bytes and it generally returns a single Word variable so it cannot directly use the @BPTR variable, let alone @BPTRINC which may exhibit some "unexpected behaviour" (aka a Bug). Furthermore, the command doesn't (wait to) "receive" a Serial Data byte, it only examines the (on-chip) Hardware Receive Buffer which might (or might not) contain a previously-received "valid" data byte. Generally, the High Byte of the returned word is used to determine IF the Low Byte contains a valid data Byte that the program can process. But if not all of the potential 256 received byte values are "possible", then one of these can be used as the marker instead.
The above is a four-stage process in a Basic Program: i.e. : Pre-Load a "marker" byte/word > Use HSERIN to "Update" the Byte/Word > Check if the marker has been changed (overwritten) > If so, extract the data byte. This seems no faster than working directly with the Hardware Receive Register(s) via two PEEKSFR commands, i.e. : Read the buffer flags (byte) > Has a (new) byte been received? > If so, then Read the received byte from the buffer. And that is before we consider a potential "Bug" in the HSERIN command :
The "Base PIC's" Serial Receive Buffer can store only two Bytes and if a third arrives before the first has been Read (by the Program) then this last byte is "lost" and the hardware (intentionally) locks up until it is Reset. This is a "fatal" error because at least one byte has been lost and probably more whilst the error is detected and the relevant Hardware is reset. This obviously sets an upper limit to the rate that complete characters can be received (and processed), but much higher baud rates are still possible, provided that there are sufficiently long gaps between the characters. The problem (Bug) with the HSERIN command is that sometimes it "thinks" that an overrun has occurred, even when it hasn't.
Thus it Resets the hardware, effectively corrupting the subsequent character(s), if they follow closely after the previous one.A few years ago I devised an alternative to HSERIN, which could reliably receive at up to 4,800 baud with a 4 MHz clock (equivalent to 38,400 baud at 32 MHz), of "concatonated" (i.e. adjoining) characters, and optionally interrupt-driven. However, looking back at that program code now, perhaps it was too "ambitious" for general purpose use, because code with an upper limit of 2,400 baud at 4 MHz (i.e. still up to 19,200 at 32 MHz) should be much easier to use and understand. I'll take another look at those programs to see if I can offer something suitable to receive High(er) baud rates (than SERIN) and to optionally measure the inter-character gap times.
Cheers, Alan.
Many thanks Alan. I used the @BPTRINC to store the incoming data and it works well. I also used the picaxe to transmit data to the PC and that worked right away with the simple SEROUT command. i ran it for a few minutes and had no errors.
I have both an oscilloscope and a cheap 8 channel analyzer but it will take me a while to get it all figured out, i know that my scope can decode serial data but it's been years since i played with that function.
I'll try to figure the time gaps once i set up the scope.
my next step is to make everything portable and then i can check the range.
all the best.
I have both an oscilloscope and a cheap 8 channel analyzer but it will take me a while to get it all figured out, i know that my scope can decode serial data but it's been years since i played with that function.
I'll try to figure the time gaps once i set up the scope.
my next step is to make everything portable and then i can check the range.
all the best.