Timeout (again)

friis

Senior Member
Hi,
I am operating 18M2 at freq. 16 (HC12BaudRate = T9600_16). I want a timeout period in real time of 23 sec. I should then set Timeout to 92000, right? I cant do that, so what to do?
best regards
torben
 

hippy

Technical Support
Staff member
You could drop the SETFREQ to M8 before the SERIN, use T9600_8, have a timeout of 46000, and restore SETFREQ M16 afterwards.
 

friis

Senior Member
Hi hippy,
I had just with difficulty got the timing between 3 wireless communicating pgms right, so I was trying to avoid that.
Thank you very much.
yorben
 

hippy

Technical Support
Staff member
The timing will be almost exactly the same. The SERIN will complete executing and you can continue at 16MHz as soon as the last character is received or, if nothing is received, it will timeout after 23 seconds and continue executing at 16MHz.
 

friis

Senior Member
Hi hippy,
I tried to simply change the freq. to T9600_8, but so far it ended in chaos. I would like ask two questions:

1. If I can download a pgm into a chip and the download is OK, can I then be sure that the chip is OK?
2. When I download I may have to make 2,3,4...attempts at downloads before I succeed - whithout touching anything between attempts. I get the message:
Error: Hardware not found on COM5!
I have checked the cable and I have checked the connections from the cable to the chip, and they are OK
torben
 

hippy

Technical Support
Staff member
Any "Hardware not found" is likely to be the program waiting in a SERIN for data or timeout, not acknowledging a download during that time. This would be entirely expected.

A Hard Reset to download reliably would be the best way to get round that problem.
 

friis

Senior Member
Hi hippy,
I am afraid you told me the same thing some years ago. Thanks for telling me again - it was as great help. Strangely enough, it is only 28X2 I have problems with.

I have run timing test on two snippets of pgm on 14M2 at 16 MHz:
1.: pause 16000. That takes 4 sec.
2.: disablebod. sleep 4.enablebod. That also gives 4 sec.

When I use them in a pgm the first one runs OK, but the second does not. Why?
I use the sleep function because I want to not having to change anything when I go from 16 LHz to 8 MHz. Is that OK?
torben
 

hippy

Technical Support
Staff member
When I use them in a pgm the first one runs OK, but the second does not. Why?
No idea. perhaps post your code then members can look at what you have, may be able to figure out why one works and the other doesn't.

I use the sleep function because I want to not having to change anything when I go from 16 LHz to 8 MHz. Is that OK?
It depends on what you are trying to achieve.
 

friis

Senior Member
Hi hippy,
Here is the pgm in principle:

Sat system Sun system
----------------------------------------------------------------------------------------------
RX:beat record received TX: beat record sent
RX:waiting for answer from Sat system

processing

pause 16000
or
disablebod
sleep 2
enablebod

TX:result of processing: serout TXpin,HC12BaudRate,(PreambleByte,PreambleByte,PreambleByte,PreambleByte,PreambleByte,SomeByte,Data1,Data2)
RX: receives result of processing

If I use "pause 16000", TX is carried out. If I use the second option, processing stops until next beat record . Why?

I use HC-12 transceiver at M16 on Picaxe 14M2.

I want to change from M16 to M8 without changing the length in real time of pauses.
torben
 

hippy

Technical Support
Staff member
If I use "pause 16000", TX is carried out. If I use the second option, processing stops until next beat record . Why?
No idea. Both of these work for me, send an "X" every 4 seconds or so up the download cable on the 18M2 I have so there's no obvious reason that nothing is sent for your code after the SLEEP.
Code:
#Picaxe 18M2
#Terminal 9600
SetFreq M16
Pause 16000
SerOut C.3, N9600_16, ("Restart - Pause 1600", CR, LF )
Do
  Pause 16000
  SerOut C.3, N9600_16, ( "X" )
Loop
Code:
#Picaxe 18M2
#Terminal 9600
SetFreq M16
Pause 16000
SerOut C.3, N9600_16, ("Restart - Sleep 2", CR, LF )
Do
  DisableBod
  Sleep 2
  EnableBod
  SerOut C.3, N9600_16, ( "X" )
Loop
 

AllyCat

Senior Member
Hi,
2.: disablebod. sleep 4.enablebod. That also gives 4 sec
I use the sleep function ...... Is that OK?.
The DISABLEBOD is not necessary (it is only included to save the last few uA of supply current drain during very long periods of time) and is "Not Recommended" because it can allow the micro to "crash".

Similarly, SLEEP is Not Recommended to time accurate periods. It uses the PIC's "watchdog" timer which is at least 10 times less accurate than PAUSE. It's rather outdated now, but to give yourself a fright, look at the online Command reference for SLEEP which (still) says:

The sleep command is not regulated and so due to tolerances in the microcontrollers internal timers, this time is subject to -50% to +100% tolerance. The external temperature affects these tolerances and so no design that requires an accurate time base should use this command.

If you just want a longer timing period than 65535 clock units (10 us @ 4 MHz) then you could simply use WAIT xxx (seconds) or a duplicated pause such as PAUSE xxxxx : PAUSE xxxxx That might also be a way to "automatically" adjust the time delay: Put one of the PAUSEs in a conditional expression "IF clockfreq = m16 THEN : PAUSE xxx : ENDIF". I'm not sure if there's a predefined variable for "clockfreq" (and don't know where to look) but if not, it could be done with a PEEKSFR (at run time) or a #DEFINE (at compile time).

Cheers, Alan. .
 

friis

Senior Member
Hi hippy and AllyCat,
I increased the "sleep 4" to "sleep 10" - and it worked! But it surprised me that while "pause 16000" really resulted in a pause of 4 sec., "sleep 10" (the use of disablebod/enablebod made no difference) resulted in a pause of 24 sec, and - also surprising - it is necessary to use "sleep 10" to make it work ("sleep 9" does not work). I am confused - what am I overlooking?

After Sun has sent a beat record it goes immediately to RX while Sat does a bit of processing before sending TX - that should not take much time - certainly not 24 sec.

When I run a test of "sleep 10" I also get a pause of 24 sec - could that really be the uncertainty AllyCat talks about?

I understood that the the use of sleep would save the most on energy and since that system runs on batteries and preferably should run 3/4 of a year without changing batteries, that is important.

I also wanted to use sleep because that would allow me to change all 3 pgms from freq M16 to M8 without disturbing their synchronisation.
torben
 

friis

Senior Member
Hi techElder,
Of course, you are right. There is no mystery in the 24 (23) sec. The mystery is that 24 sec. are needed with sleep and only 4 sec. with pause. I am getting confused.
torben
 

hippy

Technical Support
Staff member
I also wanted to use sleep because that would allow me to change all 3 pgms from freq M16 to M8 without disturbing their synchronisation.
The problem with using SLEEP is that, as AllyCat noted, the accuracy of the sleep period is not certain. A "SLEEP 10" should nominally last 23 seconds, but could last anything from 11 to 46 seconds. In most cases it probably won't be so extreme but could be. "SLEEP 10" lasts 20 seconds on my PICAXE-18M2, 4 seconds shorter than on yours. A different 18M2 could easily last 4 seconds longer, 28 seconds.

If "SLEEP 9" doesn't work for you, it seems "SLEEP 10", which works for your 18M2, would not work if you were using my 18M2.

You haven't explained how the system works; not very clearly anyway. Presumably you send a "send something" command ( your "beat record" ), then wait for a reply, before pausing and repeating that again. In the mean time, the thing getting the "send something" request, waits for that, sends a reply, then pauses, before waiting for the next "send something", hence the need for timing to match.

If that is the case then it should be possible to design both sides in such a way that neither are so sensitive to timing variations that things stop working.

I would also suggest setting aside operating at M8 and M16 frequencies for now; design for M16 operation and then apply whatever fix-ups are required to make it also work at M8. If you can create something which isn't so time sensitive there shouldn't need to be any changes anyway, no matter which is used.

And, also, set low power operation to one side for now. That can be done in ways other than using SLEEP but the means to do that, dropping to 32kHz operation for example, may simply add confusion to where we currently are..

Get it working reliably with M16, make it work at M8, make it lower power, would be the course I would choose.
 

friis

Senior Member
Hi hippy,
I now have the three pgms working together. One is running at M8, the other two are running at M16.

I suppose that means that transmission speed over the air is the same and that the transmssions are buffered and delivered to/taken from the buffer.

I have to get a new multimeter before I - regretfully - start trying to fiddle with the pgms to save energy.
torben
 

hippy

Technical Support
Staff member
Glad the programs are now working. I do have one question regarding -

serout TXpin,HC12BaudRate,(PreambleByte,PreambleByte,PreambleByte ...

Are you using HC12's or just dumb RF modules ?

If HC12's then you don't need to send the preamble bytes as the HC12 adds those itself when transmitting, filters out noise when receiving.

If dumb RF modules then there may be issues regarding your SERIN timeouts, because dumb RF modules usually won't; they are kept from timing out by noise.
 

friis

Senior Member
Hi hippy,
I use HC12 and I use PreambleByte and SomeByte to distinguish between diff. types of transmissions. I could manage with one PreambleByte, but I thought that HC12 used manchester coding. Which requires 8 bytes?
torben
 

friis

Senior Member
Hi hippy,
I have slowed down the pgms to K250 in order to save energy.

I now have a situation where I send a record:

setfreq M8
serout TXpin,HC12BaudRate,(PreambleByte,PreambleByte,PreambleByte,PreambleByte,PreambleByte,SomeByte,Data1,Data2)
Setfreq K250

and I receive:

setfreq M8
'serin [20000,Skip], RXpin,HC12BaudRate,PreambleByteRec,PreambleByteRec,PreAmbleByteRec,PreAmbleByteRec,PreAmbleByteRec,SomeByteRec,SatNoRec1,SatNoRec2
serin RXpin,HC12BaudRate,PreambleByteRec,PreambleByteRec,PreAmbleByteRec,PreAmbleByteRec,PreAmbleByteRec,SomeByteRec,SatNoRec1,SatNoRec2
Setfreq K250"

and I can change between "serin [20000,Skip],RXpin...." and "serin RXpin...."

My problem is that the latter works, the former does not.
Can I get around that problem?
torben





 

friis

Senior Member
Hi hippy,
When I say that the former does not work I mean that the pgm goes to Skip without receiving anything even though it has plenty of time to receive the transaction.
torben
 

techElder

Well-known member
When I say that the former does not work I mean that the pgm goes to Skip without receiving anything even though it has plenty of time to receive the transaction.
Your "Skip" label is where serin is supposed to branch to if no characters are received before "20000". Your description is accurate for the code shown.

While working with my HC-12 transceivers, I went through some problems. What I found out by monitoring the output of the HC-12, is that the HC-12 was sending characters that I wasn't aware of; something akin to "OK TO SEND" when I was expecting "OK".

The way I solved it was to monitor the output of the HC-12 with another HC-12 connected to an independent terminal program.
 

hippy

Technical Support
Staff member
If the second, without a timeout, works, it indicates data is being received. If the first, with a timeout, does not, it indicates data isn't being received during that timeout period. And that is likely due to some kind of timing issue, design error or oversight.

There are two immediate possibilities I can see -

That the SERIN, because it uses no qualifiers, starts and captures a few of the tail-end data bytes last sent, then timesout waiting for the rest because the next data packet hasn't arrived by the time it timesout.

Or, everything is working, but you are stuck in a permanent 'never synchronising' situation.

For example, a bus service which runs every 20 minutes. You arrive at the bus stop, wait 10 minutes, it hasn't arrived, so you go for a cup of tea. The bus sails past while you are having that tea. You arrive back at the bus stop 20 minutes after you last did, wait 10 minutes, no bus, so go for another tea, the bus sails past dead-on 20 minutes after it last did. With that approach to catching the bus you never will.

It is impossible to tell exactly what is happening without seeing both sides of the code in full.

It is best to start with simpler code, with simpler data, just using an ID byte and a single byte of data, doing that without any processing code, and without changing SETFREQ.

If that doesn't work then nothing more complicated will. If it does work you can make it increasingly more complicated and will know what you went from and to when it stops working if it does, which will help analyse what any problem may be.
 

friis

Senior Member
Hi,
techElder:
I have a "Snoop" pgm that shows that whatever I have sent via the HC-12 is also what the "Snoop" gets.
hippy:
I have made a simple transmit pgm and a simple receive pgm.
Transmit:

setfreq M8
serout TXpin,HC12BaudRate,(PreambleByte,SomeByte)
Setfreq K250

Receive:

setfreq M8
serin [16000,Skip], RXpin,HC12BaudRate,PreAmbleByteRec,SomeByteRec
'serin RXpin,HC12BaudRate,PreAmbleByteRec,SomeByteRec
Skip: setFreq K250
sertxd ("RXsunTest1: ",PreAmbleByteRec,SomeByteRec,,cr,lf)

I get the right result (U[C5] ) when I use "serin RXpin,HC12BaudRate,PreAmbleByte...." and some times the right result when I use "serin [16000,Skip], RXpin,HC12BaudRate,PreAmbleByteRec..." and other times I get U[F1]

Have I overlooked something?
torben
 

inglewoodpete

Senior Member
In the past, I have observed that the SetFreq command does not produce an immediate speed change. It appears that a short settling time is needed before the new clock speed 'locks in'. I suggest trying a short pause eg 20mS after the SetFreq command but before the SerOut and SerIn. I can't remember what delay I needed to use.
 

friis

Senior Member
Hi inglewoodpete,
I have tried to put in pause 100 and even pause 200 statements - it did not help.
torben
 

hippy

Technical Support
Staff member
I get the right result (U[C5] ) when I use "serin RXpin,HC12BaudRate,PreAmbleByte...." and some times the right result when I use "serin [16000,Skip], RXpin,HC12BaudRate,PreAmbleByteRec..." and other times I get U[F1]
It would seem to be an inter-byte gap timing issue. That "U" is being received correctly means it has caught that okay in both cases, and it's ready for the following back-to-back byte when using no timeout but not when using a timeout.
Code:
C5 = 10100011
F1 =   10001111
Without timout, it catches the second byte
Code:
      1 0 1 0 1 0 1 0     1 0 1 0 0 0 1 1
___   _   _   _   _   _   _   _       __________
   |_| |_| |_| |_| |_| |_| |_| |_____|   
    S 0 1 2 3 4 5 6 7 P S 0 1 2 3 4 5 6 7 P
   `-----------------' `-----------------'
With timeout, it misses the first bit of the second byte ...
Code:
      1 0 1 0 1 0 1 0         1 0 0 0 1 1 1 1
___   _   _   _   _   _   _   _       __________
   |_| |_| |_| |_| |_| |_| |_| |_____|   
    S 0 1 2 3 4 5 6 7 P     S 0 1 2 3 4 5 6 7 P
   `-----------------'     `-----------------'
The solution for such back-to-back issues is to run the receiving PICAXE faster so it is ready for the second byte sooner when using SERIN, or to use an X2 and background serial receive.

It may be possible to add a pause between the two bytes sent, so the receiving HC-12 doesn't receive them and put them out back-to-back. I don't have any HC-12 experience so do not know how that could or would be done.
 

friis

Senior Member
Hi hippy,
Thank you for the explanation. Following that I have increased the freq. (T9600_8 to T9600_16 and M8 to M16) and it worked.

In my test pgms I had a statement "setfreq 250". The compiler did not complain, but the pgm would not run. Only when I changed it to "setfreq K250" would the pgm run.

Is the diff. in the length of sleep for a specific chip always 10% or 50% or..., or does it vary over time.
torben
 

AllyCat

Senior Member
Hi,
In my test pgms I had a statement "setfreq 250". The compiler did not complain, but the pgm would not run. Only when I changed it to "setfreq K250" would the pgm run.
Yes, K250 is the "alias" for a byte value (number) which you can check by running SERTXD (#K250) in the simulator (it should print "50"). So the compiler is quite happy with the syntax, but the program will not run correctly with a value of 250.

The "watchdog" timer (used to time the Sleep period) is designed for minimum power consumption, NOT perfect accuracy (and is not factory calibrated), so it will vary with temperature and voltage, etc. much more than the normal clock oscillator. The Microchip data sheet is extremely pessimistic about the watchdog's accuracy (-50% to +100%), so it is up to you decide what risk you are prepared to take (but the accuracy WILL be worse than the normal clock, probably by a factor of at least 10).

Cheers, Alan.
 
Last edited:

friis

Senior Member
Hi AllyCat,
It surprises me that I can compile a pgm that will not run.
I did all this in order to save batteries, but it turns out that the consumption is 0.001 Amps whether I run at K250 or M16 and using "pause" all the while. Can that be right?
I then need around 6000 mAh to last a season which I can get from Alkaliine C-batteries.
torben
 

hippy

Technical Support
Staff member
It surprises me that I can compile a pgm that will not run.
The program probably did run, just not how you expected it to, not in a way which delivered the results you wanted.

I did all this in order to save batteries, but it turns out that the consumption is 0.001 Amps whether I run at K250 or M16 and using "pause" all the while. Can that be right?
Quite possibly, though I would have expected a few more mA. How calibrated is your equipment ?
 

friis

Senior Member
Hi,
I am using a multimeter with 3 ranges: Amp, mAmp and uAmp. When I use the Amp range I get the reading 0.001 Amp. When I use the mAmp and the uAmp range I get "OL" meaning (I suppose) "Overload".
My multimeter is a Velleman DVM855. Velleman gives the following information:

DC current: 0-400 µA / 4 mA / 40 mA / 400 mA / 4 A / 10 A
  • Basic accuracy: ± (1.2% rdg + 2 digits), ± (2.0% rdg + 3 digits) for 4 A to 10 A range
  • overload protection: 0.5 A / 500 V fuse for µA and mA range; 10 A / 500 V for 10 A range

I assume that the sentence "DC current: 0-400 µA / 4 mA / 40 mA / 400 mA / 4 A / 10 A" means that it moves the point in the reading.
They also say in the manual that the device is not calibrated when purchased, but I suppose that the basic accuracy holds.

I understand from reading the Forum that there is more than reducing the frequency I could do, but it surprised me that I could see no effect.

I have a specific problem with 18M2:

serin [65000,CloseAll], RXpin....

does not give me 65 sec. but a much shorter interval.
torben
 

hippy

Technical Support
Staff member
I have a specific problem with 18M2:

serin [65000,CloseAll], RXpin....

does not give me 65 sec. but a much shorter interval.
That should give you a 65 second timeout at 4MHz, 32.5 seconds at 8MHz, 16.25 at 16MHz and 8.125 at 32MHz.
 

AllyCat

Senior Member
Hi,

Yes, from the Command Reference: "The SETFREQ command can be used to change the speed of operation of the microcontroller from 4MHz ....... However note that this speed increase affects many commands, by, for instance, changing their properties (e.g. all pause commands are half the length at 8MHz)".

You "should" be able to use a multimeter on the mA range, but the Auto-ranging feature may be creating an issue with its (too high) resistance being inserted in series with the supply. A possible workaround could be to put a resistor of (e.g.) 1 ohm in series with the supply and measure the voltage drop across it (i.e. 1 mV represents 1 mA, etc.).

From a few posts earlier;, I would have expected the PICaxe (core) to drain somewhat over 1 mA of current at 16 MHz, but for it to fall to less than 100uA during sleep. However, there are other components (than the PICaxe) that may drain current - in particular the HC12 (IIRC a few mA quiescent current in its "low power" mode). I was surprised to see you using 9600 baud communications when the only "lower power" mode of the HC12s doesn't support 9600 baud ! Of course there are some (IMHO not trivial) methods to reduce the average power consumption of HC12s, but I don't believe you have discussed them, nor shown any program code attempting to implement them?

Cheers, Alan.
 
Last edited:

friis

Senior Member
Hi,
It occured to me, but I think the manual does not mention the effect of freq. on Timeout (it does with Pause).

To reduce power consumption of the Picaxe chip should one not reduce the freq. as much as possible - wether the Picaxe chip is computing or pausing? Going to K31 when pausing should do the job? Is there anything else one can do?

And the consumption of external components like LEDs and HC-12s should also be reduced.

I did not know that I could put the HC-12 to sleep, but I see that there is a lot on the subject on the net. I dont, however, know what IIRC and IMHO mean.

I have gotten a lot further!

torben
 

hippy

Technical Support
Staff member
It occured to me, but I think the manual does not mention the effect of freq. on Timeout (it does with Pause).
No, it doesn't seem to. We will update the online documentation.

To reduce power consumption of the Picaxe chip should one not reduce the freq. as much as possible - wether the Picaxe chip is computing or pausing? Going to K31 when pausing should do the job?
Running at lower speeds will reduce power but the program execution will slow down. In the case of K31 this may be so slow as to allow the internal watchdog to timeout and reset the PICAXE before a command completes. This can particularly be the case with PAUSE commands and others which take longer to execute than the internal watchdog timeout period.

And I should comment out all of my SERTXDs out?
It is probably sensible to use #IFDEF-#ENDIF conditional compilation so they can be automatically included while debugging but removed from the final code.
 

AllyCat

Senior Member
Hi,

From Post #37: Sorry; they're "If I Recall Correctly" and "In My {Humble} Opinion". ;)

But I'm afraid I don't agree with most of your proposals: I wouldn't remove ALL sertxds, for example a SERTXT("Program Version x.y") at the top of a program can be very useful (because it's not possible to read the code out of a PICaxe at a later date, and sometimes the "latest" version proves not to be the best ! ).

The Manual does say that "many" commands are affected by SETFREQ and in practice it's nearly ALL of them (in terms of execution time at least). The main exceptions are those with an independent oscillator such as SLEEP and NAP, perhaps READADC and WRITE, and those that switch the frequency back to 4 MHz (e.g. IRIN). But even these might be affected when you LOWER the frequency, because part of the command will still be executed at the (ridiculously slow) selected clock speed.

Even 1 MHz is "too slow" for some PICaxe commands and can allow the watchdog to cause an "unexpected" Reset. Also beware that the PIC has two "31 kHz" oscillators; only one is "accurate" (the other is related to the watchdog/sleep timer) and it appears that the k31 parameter selects the low accuracy option. The power drain is reduced to about 10% (70 uA v. 700 uA) but the processing speed to less than 1%.

So, conversely, the lowest average power drain might be achieved by running the PICaxe at maximum speed e.g. 8 times faster, (which the data sheet says consumes 6 - 7 times higher power) and then Sleeping for the remainder of the time (with negligible current drain). But I would want to examine the overall hardware and software design in considerable detail before adopting such a strategy. However, it does appear to be the method used by the HC12 in its lowest power mode, i.e. a brief burst of data at 250 kbits/sec "to air" (with its associated reduction of range) followed by a long period of inactivity.

Cheers, Alan.
 
Top