Picaxe 08M2 433 project

fntslz

New Member
Hello to all,
I have a transmitter at 433 to which I replaced his original pic12c580 with the picaxe 08m2.
I would like to be able to transmit with the picaxe a signal equal to this in the picture.
Unfortunately I can not.
I tried to make it with the pauseus and pulseout commands but it does not work.
It would seem that a pulse is the next pauseus command does not work ... i can not drop below 1ms.
Anyone could give me a hand? Thanks.

Excuse me my English.


433_picaxe.jpg
 

westaust55

Moderator
Welcome to the PICAXE forum.

For background information reasons it might be easier for folks to understand what is involved to help you if you can provide a link to the original project (the one with the pic12c580).

I note that while the pulses are in a similar sequence in the "bursts" shown they do vary for the same pulse between each burst.

What speed are you running the 08M2 PICAXE chip at? You may need to run at a faster clock speed (see the SETFREQ command).
 

fntslz

New Member
ok thanks..
i try to setfreq.
but i can use the doble comand pulseout?
i first comand for the pulse time and the second comand for the pulse time down?
Thanks
 

AllyCat

Senior Member
Hi,

Welcome. It looks as if the waveform basically has two different "Low" times of either 400 or 750 us and two "High" times of 260 or 600 us. That should be possible, but as WA says, you will need to use a higher clock frequency. Also, because the PICaxe interpreter is "slow", you need to take into account the execution times of every instruction.

If you need to generate only that particular waveform, then it is probably easiest to use use simple "in line" code. The basic information you need is that a PULSOUT pin,1 takes about 570 PIC "instruction cycles" and PAUSEUS 1 takes about 720 instruction cycles. But then the pulse/pause time increases by exactly 10 instruction cycles for each integer increase of the constant. Each (PIC) instruction cycle takes exactly 1 us at the default 4 MHz clock frequency for M2s, so it looks that you need to use a 16 MHz clock (i.e. SETFREQ m16), but a higher frequency could give better resolution/accuracy.

If we assume that the first few time intervals in your pulse train are: 260, 400, 600, 750, 260, ....us then the following code (not tested) might get close to what you want (but I'm not sure how the time delays are spread before and after each pulse) :

Code:
setfreq m16
pulsout pin,48      ; 1040 - 560 / 10
pauseus 89          ; 1600 - 710 / 10
pulsout pin,184     ; 2400 - 560 / 10
pauseus 229        ; 3000 - 710 / 10
pulsout pin,48
....  etc.
However, those values might need to be adjusted a little to give better accuracy.

If you need to generate changing data then the (explicit) integer numbers can be replaced by a variable such as b1. This can be read from a RAM or EEPROM lookup list (such as b1 = @bptrinc), perhaps inside a program loop. Or in some cases the TOGGLE pin instruction can be used in place of HIGH pin and LOW pin commands.

Cheers. Alan.
 
Last edited:

pxgator

Senior Member
In the past I've had very good luck with pulsout and pulsin at the higher clock rates but not so with pauseus.
So, I set up a PIC16F1619 with a 16mhz crystal and programmed it to use it's 24 bit signal measurement timer
to accurately measure high and low pulsewidths with one microsecond resolution. The results were interesting
indeed. Pulsout is very accurate but pauseus.....well..?? I will gladly repeat some tests if some of the PICAXE
experts post the code. It seems like a dummy blocking command that could be repeated in a macro that takes a
minimum amount of time is needed to replace pauseus for encoding a serial bit stream..??

http://ww1.microchip.com/downloads/en/DeviceDoc/40001770C.pdf

Code:
[color=Navy]#picaxe [/color][color=Black]08M2[/color]
[color=Navy]#no_data[/color]

[color=Blue]setfreq m16   
symbol pOUT [/color][color=DarkCyan]= [/color][color=Blue]C.1[/color]

[color=Green]#rem
DO                  ;results
  pulsout pOUT,48   ;high pulse = 121 usecs (120 expected...very good!)
  pauseus 89        ;low pulse = 664 usecs (223 expected)
LOOP
#endrem

#rem
DO                  ;results
  pulsout pOUT,184  ;high pulse = 460 usecs (460 expected...very good!)    
  pauseus 229       ;low pulse = 1013 usecs (573 expected)      
LOOP
#endrem[/color]

[color=Blue]DO                  [/color][color=Green];results
  [/color][color=Blue]pulsout pOUT[/color][color=Black],[/color][color=Navy]40   [/color][color=Green];high pulse = 101 usecs (100 expected...very good!)
  [/color][color=Blue]pause [/color][color=Navy]0           [/color][color=Green];low pulse = 378 usecs (??? expected)
  ;pauseus 0        ;low pulse = 411 usecs (??? expected)   [/color]
[color=Blue]LOOP[/color]
P.S. Pulsout is accurate and consistent. A pulsout command with an additional parameter
that would determine if a high or low pulse would be output would be a welcome addition
to the PICAXE system.
 
Last edited:

inglewoodpete

Senior Member
In the past I've had very good luck with pulsout and pulsin at the higher clock rates but not so with pauseus.
So, I set up a PIC16F1619 with a 16mhz crystal and programmed it to use it's 24 bit signal measurement timer
to accurately measure high and low pulsewidths with one microsecond resolution. The results were interesting
indeed. Pulsout is very accurate but pauseus.....well..?? I will gladly repeat some tests if some of the PICAXE
experts post the code. It seems like some dummy command that could be repeated in a macro that takes a
minimum amount of time is needed to replace pauseus for encoding a serial bit stream..??
PICAXEs use an interpreted coding of the user program, rather than a compiled program. Added to this is the 5(?)-bit tokenised coding and you have timing issues with short time periods. Not only does the PICAXE firmware have a time overhead to read and interpret each command and its associated data but the time taken to read the code will vary in length due the location and 'packing' of the 5(?)-bit commands in the 8-bit program memory.

Back to the original post. Not an easy task with a PICAXE M2 series.

My immediate thought was to use SPIOut (ShiftOut) and just use the data pin (ignore the clock pulses). However, the 08M2 does not support SPI in firmware. The smallest PICAXE that uses hSPIOut is the 20X2.

If PauseUs+PulsOut cannot be used the reliably reproduce the data, you may be able to use hSerOut but this will require a lot a testing and patience. The trick will be to carefully align the asynchronous serial start and stop bits to conform with the 1's and 0's of the data. I have successfully used hSerOut at up to 250kbits/sec, so it will be fast enough. It will depend on whether the correct bit pattern can be reproduced.
 
Last edited:

pxgator

Senior Member
@inglewoodpete

Good information Sir, I was hoping we could help the OP accomplish what he wants to do.
But it seems like this might be a difficult task. This would be very easy to do with C code
but maybe some others will chime in with opinions to help out the OP.

Cheers to All

P.S. It seems pretty obvious that pulsout must be a blocking command..??
 

pxgator

Senior Member
In the past I have used PICAXE serout and serin commands with a 08M2 at N1200_4 baud with 315 mhz OOK style of transmit/receive
systems with very good results. If the OP could replace the receiver circuit with an M2 chip this might be an easy solution.

Cheers to All
 
Last edited:

PhilHornby

Senior Member
I have a transmitter at 433 to which I replaced his original pic12c580 with the picaxe 08m2.
I would like to be able to transmit with the picaxe a signal equal to this in the picture.
Unfortunately I can not.
I tried to make it with the pauseus and pulseout commands but it does not work.
It would seem that a pulse is the next pauseus command does not work ... i can not drop below 1ms.
Have a read through this thread: http://www.picaxeforum.co.uk/showthread.php?28644-Picaxe-instruction-timing-repeatability - and the code snippets that resulted. They may help.
 

hippy

Technical Support
Staff member
One trick to minimise position dependent timing of PICAXE commands is to keep the timing fixed by having code located at the start of the program and feeding timing via the scratchpad or RAM. One example is ...

Code:
PowerOnReset:
  Goto Main

OutputPulses:
  bPtr = 0
  Do
    Toggle C.1
    PauseUs @bPtr
  Loop Until @bPtrInc = 0
  Return

Main:
  Low C.1
  bPtr = 0
  @bPtrInc = 10 ; High for 10
  @bPtrInc = 20 ; Low  for 20
  @bPtrInc = 40 ; High for 40
  @bPtrInc = 0  ; Low  and done
  Do
    Gosub OutputPulses
    Pause 1000
  Loop
This will output something like ...

Code:
    _    _________
___| |__|         |___
 

pxgator

Senior Member
Some test results:

Code:
[color=Navy]#picaxe [/color][color=Black]08M2[/color]
[color=Navy]#no_data[/color]


[color=Blue]setfreq m16   [/color]


[color=Black]PowerOnReset:
  [/color][color=Blue]Goto [/color][color=Black]Main

OutputPulses:
  [/color][color=Purple]bPtr [/color][color=DarkCyan]= [/color][color=Navy]0
  [/color][color=Blue]Do
    Toggle C.1
    PauseUs [/color][color=Purple]@bPtr
  [/color][color=Blue]Loop Until [/color][color=Purple]@bPtrInc [/color][color=DarkCyan]= [/color][color=Navy]0
  [/color][color=Blue]Return[/color]

[color=Black]Main:
  [/color][color=Blue]Low C.1
  [/color][color=Purple]bPtr [/color][color=DarkCyan]= [/color][color=Navy]0                        [/color][color=Green];results 
  [/color][color=Purple]@bPtrInc [/color][color=DarkCyan]= [/color][color=Navy]10 [/color][color=Green]; High for 10     ;526 to 527 usecs HIGH
  [/color][color=Purple]@bPtrInc [/color][color=DarkCyan]= [/color][color=Navy]20 [/color][color=Green]; Low  for 20     ;550 to 551 usecs LOW
  [/color][color=Purple]@bPtrInc [/color][color=DarkCyan]= [/color][color=Navy]40 [/color][color=Green]; High for 40     ;601 to 602 usecs HIGH
  [/color][color=Purple]@bPtrInc [/color][color=DarkCyan]= [/color][color=Navy]0  [/color][color=Green]; Low  and done
  [/color][color=Blue]Do
    Gosub [/color][color=Black]OutputPulses
    [/color][color=Blue]Pause [/color][color=Navy]1000
  [/color][color=Blue]Loop[/color]
Cheers to All

P.S. The pulses are stable and repeatable, perhaps some tinkering with clock
speeds and pauseus values a reasonable bit stream could be achieved as long
as the bit frames per second requirements were not too fast.
 
Last edited:

Goeytex

Senior Member
Looks like the OP may have gotten what he needed and flew the coup. It happens.

BTPR, Pointers, scratchpad, lookups , etal... May be a bit much for a newbie. My guess is that Allan's approach did the trick and at least got him in the ballpark.

As Allan indicated, the example shows only 4 possible timing values: Highs of either 260us or 600us and lows of either 400us or 750us. So I created a constant for each.

Pulsout is easy. At 32MHz Clock Pulseout values are 260 / 1.25 = 208 & 600 / 1.25 = 480.

Pauseus is not so easy due to the overheads involved is probably best done via trial and error with a scope or other measuring device (if possible). In any case when called back to back with Pulseout ... 400us correlates to Pauseus 215 and 750us correlates to Pauseus 481. I used a scope. Here is the resultant code.

Code:
#Picaxe 08M2
#No_Data 
SetFreq M32


[COLOR="#008000"]'// Mark Times[/COLOR]
Symbol H260 = 208
Symbol H600 = 480


[COLOR="#008000"]'// Space times[/COLOR]
Symbol L400 = 215
Symbol L750 = 481  

Low C.2

Do

    Pulsout C.2, H260
    Pauseus L400
    
    Pulsout C.2, H600
    Pauseus L750 
    
    Pulsout C.2, H260
    Pauseus L400
    
    Pulsout C.2, H600
    Pauseus L750  
   
    Pulsout C.2, H260
    Pauseus L400
    
    Pulsout C.2, H600
    Pauseus L400    
    
    Pulsout C.2, H600
    Pauseus L750   

    Pulsout C.2, H260
    Pauseus L750 
    
    Pulsout C.2, H260
    Pauseus L400
    
    Pulsout C.2, H600
    Pauseus L750  
    
    Pulsout C.2, H260
    Pauseus L400
    
    Pulsout C.2, H600
    Pauseus L400   
    
    Pulsout C.2, H600
    
    Pauseus 9040  [COLOR="#008000"] '//  1130 / 1.25     [/COLOR]

Loop
 

pxgator

Senior Member
Well done Goeytex! I tested you're code with my measurement system...the pulsout's were spot on
and the pauseus's were within +/- 5 microseconds which would be plenty good enough.

Cheers to All
 

AllyCat

Senior Member
Hi,

Yes, Goey is correct on all counts (pun intended) and probably the OP has now flown. There are errors in my calculation of the numbers in post #5 ; the PULSOUT 1 command does take about 570 PIC instruction cyles (570 us at 4 MHz) to execute, but the pulse generated is of course only 10 ICs (10 us) in duration :

So the PULSOUT values in #5 should be increased by 56, to 104 and 240 (cf Goey's values of 208 and 480 @ 32 MHz), and the PAUSEUS values reduced by 56 (to 33 and 123). Those are all byte values (at m16) so a simple "list" in RAM or EPROM could be used if a "variable" data output were required.

However, there are considerable issues in attempting to write a loop/lookup waveform generating program for the values specified by the OP. One problem is that @bptr is a byte variable, so the maximum PULSOUT @bptr is 2550 us at 4 MHz, or less than 320 us at 32 MHz. Similarly for the maximum differential delay of PAUSEUS @bptr, which the OP specified to be 340 - 350 us.

There's no possibility of creating a "TOGGLE" loop for the required pulse period of 160 us, even at 32 MHz, and something like the following will still struggle to achieve the required delays, even with additional maths operations to increase the pause values. One of those "rare" occasions when the PICAxe interpreter is too slow. ;)

Code:
DO
    HIGH pin
    PAUSEUS @bptrinc
    LOW pin
    PAUSEUS @bptrinc
LOOP WHILE bptr < BUFFERLENGTH
Note that the PICaxe WORD qualifier is unexpectedly rather slow; generally it's faster to use (for example) READ b0,b1 in preference to READ WORD w0 . Also strangely, it may be easier to receive/decode this pulse train, because there may be sufficient information stored (@bptrinc) in only the High byte of a received word.

Cheesr, Alan.
 

hippy

Technical Support
Staff member
Well done Goeytex! I tested you're code with my measurement system...the pulsout's were spot on and the pauseus's were within +/- 5 microseconds which would be plenty good enough.
The problem really comes if one has two sequences to output. If one is aligned differently in memory then the code almost identical to that used elsewhere may not have the same timing as the other. That is more likely to affect the PAUSEUS timing than the PULSOUT timing.

The timing may not be so badly out that it matters but in some cases it can be.
 

fntslz

New Member
Ok thanks .. i solved ..
I did various tests is now I am able to send the code correctly ..
Thank you all for help.
 
Top