08M2 TX/RX Project

lbenson

Senior Member
I don't know that anyone has done Manchester encoding on an 08M2, and then sent it directly to a 433mhz (for instance) transmitter. The RFout command on the 14M2 achieves this--or you can use serout to an NKM2401. If you have managed to send a Manchester encoded transmission at the right baud rate, then yes, you only need the NKM2401 on the rx.

If your client can only transmit, then you risk undetected collisions. The risk may be small if transmissions are infrequent, or may be inconsequential, but if the data must get through, then you need two-way communication.
 
I don't know that anyone has done Manchester encoding on an 08M2, and then sent it directly to a 433mhz (for instance) transmitter. The RFout command on the 14M2 achieves this--or you can use serout to an NKM2401. If you have managed to send a Manchester encoded transmission at the right baud rate, then yes, you only need the NKM2401 on the rx.

If your client can only transmit, then you risk undetected collisions. The risk may be small if transmissions are infrequent, or may be inconsequential, but if the data must get through, then you need two-way communication.
I guess I wasn't clear. If a given sequence is hard coded (ie as a fixed, Manchester Sequence) into a PIC as a sequence of conditioning data plus a unique ID, and transmitted to a receiver that has either a 14M2 or similar PICAXE or an 08M2 with NKM2401, would that not be equivalent to a transmitter/receiver combo with the Manchester Encoding protocols.

One of my problems is that the NKM2401 seems to require 5v, but I'm space limited to 3.7v using LiPo or Li-ion. If the 2401 could be programmed with a simple ID, that would be idea but I guess that's the idea behind the 14M2, not only capable of Manchester Encoding but also handling the logistics of things. Too bad a smaller chip isn't available.

I agree that two way communication would be best, but unidirectional might be adequate. ;)

Thanks
Doug
 
Last edited:

lbenson

Senior Member
Maybe ... I'm not really sure of the details there.

>Too bad a smaller chip isn't available.

There's the smd 14m2. I find it solderable--barely.
 

hippy

Technical Support
Staff member
If a given sequence is hard coded (ie as a fixed, Manchester Sequence) into a PIC ...
I think it's time to step back and look at the options and bear in mind what the problem is you are trying to overcome. That problem seems to be that you cannot SERIN wireless from a dumb RF module and reliably use timeout when there's no data being transmitted - that is correct.

The two options to overcome that are to use a second PICAXE or an NKM2401 receiver at the receiving end. There is no option which does not require two chips at the receiving end.

If you use another PICAXE the transmitters can be a single PICAXE using SEROUT direct to dumb RF modules.

If you use an NKM2401 the sending PICAXE will either have to support the RFOUT command or also use an NKM2401 transmitter to drive the dumb RF module.

The three main options you have are ...

SEROUT ---------------> TX ~~> RX --> PICAXE (SERIN) <==> PICAXE

RFOUT ----------------> TX ~~> RX --> NKM2401 <=======> PICAXE

SEROUT --> NKM2401 --> TX ~~> RX --> NKM2401 <=======> PICAXE

But you could replace the receiving NKM2401 with a PICAXE which supports RFIN ...

RFOUT ----------------> TX ~~> RX --> PICAXE (RFIN) <====> PICAXE

SEROUT --> NKM2401 --> TX ~~> RX --> PICAXE (RFIN) <====> PICAXE

You could program a PICmicro so it churns out a stream that an NKM2401 can read and understand ( replacing the transmitting PICAXE using RFOUT in the second option above ), but you would need to program a PICmicro for that and then use an NKM2401 at the receiving end. That doesn't seem to give any advantage I can see over using a PICAXE that supports RFOUT or the first option which can be implemented using off the shelf parts.
 
Last edited:
I think it's time to step back and look at the options and bear in mind what the problem is you are trying to overcome. That problem seems to be that you cannot SERIN wireless from a dumb RF module and reliably use timeout when there's no data being transmitted - that is correct.

The two options to overcome that are to use a second PICAXE or an NKM2401 receiver at the receiving end. There is no option which does not require two chips at the receiving end.

If you use another PICAXE the transmitters can be a single PICAXE using SEROUT direct to dumb RF modules.

If you use an NKM2401 the sending PICAXE will either have to support the RFOUT command or also use an NKM2401 transmitter to drive the dumb RF module.

Th five options you have are ...

SEROUT ---------------> TX ~~> RX --> PICAXE (SERIN) <==> PICAXE

RFOUT ----------------> TX ~~> RX --> NKM2401 <=======> PICAXE

SEROUT --> NKM2401 --> TX ~~> RX --> NKM2401 <=======> PICAXE

RFOUT ----------------> TX ~~> RX --> PICAXE (RFIN) <====> PICAXE

SEROUT --> NKM2401 --> TX ~~> RX --> PICAXE (RFIN) <====> PICAXE

You could program a PICmicro so it churns out a stream that an NKM2401 can read and understand ( replacing the transmitting PICAXE using RFOUT in the second option above ), but you would need to program a PICmicro for that and then use an NKM2401 at the receiving end. That doesn't seem to give any advantage I can see over using a PICAXE that supports RFOUT or the first option which can be implemented using off the shelf parts.

Thanks for the detailed responses.
I have significantly greater freedom (space and power) at the receiver end than I do at the transmitter end of things.

If I understand you correctly, it is possible to use a single PICAXE at the transmitter end of things, sending out a string that is "readable by a NKM2401 decoder that would only deliver a valid signal to the second PIC when an appropriate signal was received by the receiver and decoded by the 2401 (or, presumable a higher power PICAXE like a 14M2 that has an RFin ability to decode the signal DIRECTLY, AVOIDING A TWO PIC option).

The problem here comes if two XTMRs are operating at the same time. But, if the first transmitter is literally powered off or put into a slep state, 1) before the second transmitter operates or 2) is shut off before the second transmitter sops sending its unique ID, this should work, correct?

Doug

I see that the NKM2401 is just a PIC programmed with a hex code available for DL for "individual" ie not commercial use. Would it be possible to simply add a unique ID to that chip so that when it receives a trigger signal, it sends an ID signal plus conditioning code to the transmitter?
 

hippy

Technical Support
Staff member
If I understand you correctly, it is possible to use a single PICAXE at the transmitter end of things, sending out a string that is "readable by a NKM2401 decoder that would only deliver a valid signal to the second PIC when an appropriate signal was received by the receiver and decoded by the 2401
Yes, providing the transmitting PICAXE supports the RFOUT command.

(or, presumable a higher power PICAXE like a 14M2 that has an RFin ability to decode the signal DIRECTLY, AVOIDING A TWO PIC option).
No; because a PICAXE RFIN command blocks until it receives data. There is no single chip solution to do what you want.

Added : But in all the tangents I may have misunderstood what you want. Is blocking a problem or not ?

If blocking isn't a problem then yes, you can use a single PICAXE and its RFIN command.

But you could equally use a transmitting PICAXE with SEROUT and a recieving PICAXE with SERIN, so the NKM2401 / RFOUT / RFIN issue seems rather moot other than that offers more reliability and ease of use.

The problem here comes if two XTMRs are operating at the same time. But, if the first transmitter is literally powered off or put into a slep state, 1) before the second transmitter operates or 2) is shut off before the second transmitter sops sending its unique ID, this should work, correct?
It should.

I see that the NKM2401 is just a PIC programmed with a hex code available for DL for "individual" ie not commercial use. Would it be possible to simply add a unique ID to that chip so that when it receives a trigger signal, it sends an ID signal plus conditioning code to the transmitter?
I doubt it would be simple and may not be possible, technically and in terms of its copyright and licensing. You would have to reverse engineer the source code from the .HEX file and then modify that source.
 
Last edited:
I'm likely mis stating my needs here, largely based on my conflating the transmitter/receiver side of things.

If we completely separate the XTMR side of the equation from the RCVR side of the equations.

Is there a simple single PICAXE chip which can 1) transmit a conditioning stream with unique ID, that can turn itself off after a predetermined period of time or, specific trigger signal (using SerOUT or RFout ie 08M2 or 14M2) that will then activate a simple ASK 433mhz that's is received by:

A simple ASK 433mhz RCVR that is connected to a 2401 decoder chip that sends a qualifying signal to a PICAXE chip that 1) recognizes the ID of the qualifying signal and reports this in some way (LCD/LED1, 2, 3 etc).

Or, does the hard reality dictate that once a PICAXE chip is asked to send information to the transmitter data pin, it is blocked from doing anything else (until the data has been sent/until some arbitrary time out is reached? ? ?)

Doug
 

hippy

Technical Support
Staff member
Multiple PICAXE can transmit their identifiers ( and any data they might need to ) to a receiving PICAXE and that receiving PICAXE can determine which sender communicated with it and act on that and/or any data received.

And quite simply too. You don't need RFOUT or RFIN commands or NKM2401 chips but you can use them if you want to.
 
Multiple PICAXE can transmit their identifiers ( and any data they might need to ) to a receiving PICAXE and that receiving PICAXE can determine which sender communicated with it and act on that and/or any data received.

And quite simply too. You don't need RFOUT or RFIN commands or NKM2401 chips but you can use them if you want to.
You wouldn't have a tutorial URL handy on this, would you?
Oh, I should ask. Can this be done wirelessly with simple ASK transmitter/receiver modules? :)
Thanks Hippy
Doug
 
Last edited:

lbenson

Senior Member
>does the hard reality dictate that once a PICAXE chip is asked to send information to the transmitter data pin, it is blocked from doing anything else (until the data has been sent/until some arbitrary time out is reached? ? ?)

No (other than the brief time it takes the picaxe to execute the send)--blocking is on the receiving end. If you execute SERIN, your program will sit until it receives something (or, if you have a qualifier, until it receives that qualifier and the number of additional characters you have specified).

The question which hasn't been answered is whether blocking on the receiving end is a problem for you. For instance, one transmitter can send "Unit1", another "Unit2", and so on. On the receiving end, you could have
Code:
SERIN pin,baudmode,("Unit"), ID
Select ID
  Case "1"
  Case "2"
End Select
Then you do whatever you want when you identify the unit which has made the transmission. But until you receive a transmission with "Unit" and another character, your program will sit at the Serin statement (i.e., will be blocked). "Timeout" can get you past this if your connection is wired, but if wireless, noise on the receiver will prevent the timeout from occurring.

SERIN with wireless is blocking. RFin is blocking. Polling for "Data Available" on the NKM2401 (or another picaxe) is not blocking.
 
Last edited:
Since the only thing the RCVR / PICAXE combination is doing is waiting for a transmitter to send its unique ID, being "blocked" as I seem to understand it, is unimportant. Once it receives the qualifier and a recognized ID (ID1, ID2, ID3 etc) the PICAXE will simply do "something" ie light a specific LED, and then wait for the next transmitter.

Sound reasonable?
Doug
 

rossko57

Senior Member
I guess that waiting transmission isn't quite the only trick the Rx has to do ... somehow, the LEDs need to be turned off in absence of transmission?

That could be where the timeout comes in; setup the TX to each squawk their ID burst at different "random" intervals. Interval based on ID say. Different, so that if there is a clash it will go away at next interval.
Set up the RX to listen for IDs as described and turn appropriate LEDs on. Use a timeout much longer than the Tx interval - if you get timeout then switch all LEDs off, before returning to listening.

Which leaves the case where two TX were active, but now only one. Perhaps have the RX routine keep a burst counter. After 10 bursts from any TX, switch off all LEDs. You might get some visible flicker - do you care?
 

hippy

Technical Support
Staff member
Sound reasonable?
Yes.

There are no tutorials but it is simple enough and there has been considerable discussion on the forum in the past on using dumb RF modules.

A sender has to emit a preamble, pause, emit a synchronisation qualifier then its identifier and/or data. For example, a number of 08M2 PICAXE could act as wireless doorbells, the 1 would identify which 08M2 / doorbell it was ...

Code:
Do
  If pin3 = 1 Then
     High TX_POWER
     Pause
     SerOut TX_DATA, TX_BAUD, ("UUUUUUUUUUUUUUUU")
     Pause 10
     SerOut TX_DATA, TX_BAUD, ("DOOR", [b]1[/b] )
     Low TX_POWER
  End If
Loop
The receiver would simply look for the "DOOR" qualifier and read the identifier which follows it ...

Code:
Do
  SerIn RX_DATA, RX_BAUD, ("DOOR"), b0
  SerTxd( "Doorbell ", #b0, "Pushed", CR, LF )
Loop
That's the basic gist of things anyway.
 
Thanks guys,
I've used up more than my fair share of questions. Now it's time to get back to the manual!
Oh, wrt the possible flickering LED's potential problem. It really isn't a problem. In fact, the LED's don't really even need to go off, as long as you know the order that they went on. :)

A better example might be a vibrating pager motor as the annunciator. One pulse for XTMR number 1, two pulses for number 2 etc.

Thanks again for all your help!

Doug

(Quick aside for those with CC2500 experience. Can that tranceiver store a unque ID and is that register available through the software that TI offers? Perhaps one of the R/W "test" registers? )
 
Top