Problem with pulsin command

[abenn]

I have written a routine for a PICAXE 08 to flash of two strobe lights on a model aircraft -- double-flashes at about 1-second intervals. The code is:-

main:
		let b2= 0
		let b0= 0
start_loop:	if b2= 0 or b2= 12 then green_on
label_02:	if b0= 0 or b0= 12 then red_on
label_03:	if b2= 3 or b2= 15 then green_off
label_04:	if b0= 3 or b0= 15 then red_off
label_05:	let b2=b2+ 1
		let b0=b0+ 1
		if b0> 200 then red_reset
label_06:	if b2> 205 then green_reset
label_07:	pause 0
		goto start_loop
green_reset:	let b2= 0
		goto label_07
green_on:	high 2
		goto label_02
green_off:	low 2
		goto label_04
red_on: 	high 0
		goto label_03
red_off:	low 0
		goto label_05
red_reset:	let b0= 0
		goto label_06

The reason for incrementing two variables is so that I can stagger the flashes slightly, as you often see on real aircraft.

I've written another routine that, when it gets a signal from a radio-control receiver, will switch "landing lights" on and off. The code for this is:-

main:
label_1F:	 pulsin 3,1,w1
		if w1< 150 then label_11
		high 0
		goto label_1F

label_11:	low 0
		goto label_1F

My problem is, when I combine the functions by inserting the landing lights code into the strobe loop, (a) it slows the sequence down by about a factor of 3 and (b) it hangs if there is no signal from the receiver

I can sort the first problem by reducing the values of the constants to compensate for the slower running, but is there any simple way that I can detect a no-signal situation? I would have thought it's the same as pulsin = 0, but that seems not to be the case because that situation is already covered by w1<150.

 

[manuka]

Model aircraft projects are certainly getting to the stage where ground observers will need a " is it a high flying plane or a low flying model" double take! At least your setup is spared synchronized machine guns as well.

It looks as if you are a victim of the old PICAXE SERIN hangout blues. Such woes relate to a SERIN command not timing out, & thus causing an endless wait for data. Diverse workarounds have evolved (some involving 2 PICAXEs), but before things go off on a tangent suggest you please specify your RC details.

 

[BeanieBots]

Pulsin should not "hang" when there is no pulse.
It will return 0 after about 0.65 seconds.
You could factor this into your code so that your pauses are shorter when there is no signal.

 

[abenn]

Manuka: The machine guns will come later

I've already considered using two PICAXES (one for the strobes function, and another for the landing lights) so that the hangup in pulsin won't affect the timing of the strobes. But as a newbie I thought there must be a more elegant way around the problem.

My RC transmitter and receiver are Futaba. Output pulses range, I believe, from 75ms to 225ms, hence my choice of w1<150 as the point at which the switch operates. With the receiver and transmitter switched on it does switch at 50% of the control-stick movement, as expected, and the srobes keep flashing without interruption. With the transmitter switched off, or with the circuit disconnected from the receiver and powered independently, the strobes flash occasionally and sometimes stay on for extended period -- until I pull the power plug

Given that the transmitter should always be switched on when the receiver is, I could also leave the circuit as it is.

You mention the SERIN hangout blues. Was that a slip of the tongue, or is SERIN a function that could detect signal or no-signal before I use PULSIN to measure the pulses?

BeaniBots: Maybe my circuit isn't actually hanging. But 0.65 seconds delay for each loop is unacceptable because the circuit is relying on the loop being completed about 50 times per second in order to produce the correct flash rates. Strange thing is, if it were only a 0.65 second delay the strobes should still be flashing regularly, but about 10 times slower than normal. That is definately not the case

 

[Dippy]

Why can't you just check the pin status high/low?
If you need to check duration of pin status you can just have it in a Do While Loop or similar.

 

[abenn]

Why can't you just check the pin status high/low? ...

Sorry, I'm relatively new to this and can't see what code I would use to achieve that. Would it be able to differentiate between a pulsed signal (which I can then count using PULSIN) and no signal at all?

I don't even know how the no-signal scenario, which the PULSIN command seems to hang on, differs from a signal with zero pulses.

 

[manuka]

650ms certainly isn't a SERIN hangup, as PICAXE SERIN cause an endless thumb twiddling wait. Are your RC signals not serial? Just pulses? I don't know enough about the nature of your RC - maybe I was on a meander (or mortgage bashing) when this aspect of my wireless electronics exposure would have been otherwise encountered? Stan

 

[BeanieBots]

@Manuka, RC radio transmission is either PPM or PCM. That is decoded by receiver into each channel which is PWM. Typically 1mS to 2mS pulse with 20mS fixed frame rate. No 'serial' data involved.

@aben.
Maybe if you could state the required 'strobe' light sequence in plain terms we could work out a way of maintaining the correct flash rate/sequence whilst still checking for RC pulses and taking action without effecting the rate when there are no pulses.

eg
pulsin pin,var
if var=0 then flashRateWhenNoSignal
code for flash with signal here...

if var > 150 then
code for gear down here...
else
code for gear up here...
endif

OR
as suggested by Dippy
make a loop that checks the siganl line and use your own timeout. That way your loop would only vary by the same amount as the pulsewidth of the signal.

There is no way out of the time limit on pulsin. If there is no pulse, it just has to sit there waiting for the pulse until it times out. The time is set in firmware at 0.65536s which just happens to be the amount of time required for a word variable to wrap.

 

[manuka]

BeanieBots- although my kids have had the usual swag of RC toys, the nature of their control data was not something I'd ever pondered. Thanks! This could be of interest to DrAcula in the Aussie bush?

 

[BeanieBots]

With your plethora of radio knowledge I'm stunned you're not familar with the standard. There are some very good articles splashed around on here that go into very deep detail on both the PPM and PCM methods. Worth a browse.
Not sure how useful it would ever be for sending "data" but certainly useful for sending the odd byte (well nibble) between PICAXEs without suffering the "the old PICAXE SERIN hangout blues"

 

[manuka]

BB- stunned indeed, or perhaps I'd forgotten. My lifetime of wireless wrangling has largely been at both higher freqs (UHF/µwave) & lower (HF). I'm familiar enough with Pulse Coding variants,BUT (having only observer interest in model aircraft/boats) I've never explored or followed hobby RC technologies. Yes- such people do exist, even though we must rank with those whose dogs litter footpaths. But wait- come to think of it- I do now recall some RC hacking @ ~35 MHz back in the mid 60s, a mere 40 years back. The image is hazy, but B batteries,dynamotors & WW2 era valve gear festoon the field. Have things moved on since then? Stan

 

[Wrenow]

One pretty good discussion of R/C PWM encoding is at: http://www.mh.ttu.ee/risto/rc/electronics/radio/signal.htm

You should not be having a problem with the pulsin timing out unless the TX or RX is turned off, as there will be a pulse at least every 20ms. I have not gone through the code thoroughly yet, but isn't B2 one of the bits of W1?

I am also thinking that one of the reasons for the increase in time is that you are calling the pulsin routines on the landing lights in the middle of your loop, thus waiting as much as 18-19ms additional each loop. One thing to consider is to do all the plusin reads, in channel order, at once. This will give you an approximately 20ms pause to start with.

Cheers,

Wreno

 

[abenn]

@Manuka, RC radio transmission is either PPM or PCM. That is decoded by receiver into each channel which is PWM. Typically 1mS to 2mS pulse with 20mS fixed frame rate. No 'serial' data involved.

@aben.
Maybe if you could state the required 'strobe' light sequence in plain terms we could work out a way of maintaining the correct flash rate/sequence whilst still checking for RC pulses and taking action without effecting the rate when there are no pulses.

eg
pulsin pin,var
if var=0 then flashRateWhenNoSignal
code for flash with signal here...

if var > 150 then
code for gear down here...
else
code for gear up here...
endif ...

Thanks BeanieBots I've already covered the situation where the pulse = 0 with if w1<150.

In plain terms I'm using two variables (b0 and b2) which increment by 1 each time the loop is performed. When they reach 95 and 100 respectively, they reset to 0. The different reset values are to make the two strobes gradually go out of sync. During each loop each LED switches on when its variable = 0 or 10, and off when its variable = 3 or 13. That means that there's a double-flash with the LEDs on for 3 loops and off for 7 loops, followed by a long off for about 90 loops. I don't know what the timing is in seconds, but without the landing light routine it results in a double-flash about every second, and looks right

Adding the pulsin 3,1,w1 ... routine into the loop (it has to be in the main loop, doesn't it?) slows the whole thing down so that I have to reduce the values of all the variables to about 1/3 of what they were. It works just fine like that so long as the RC receiver is sending a signal to the PICAXE. If there is no signal from the receiver it sometimes flashes one of the leds a couple of times, but then seems to hang with maybe one of the leds permanently lit

... OR
as suggested by Dippy
make a loop that checks the siganl line and use your own timeout. That way your loop would only vary by the same amount as the pulsewidth of the signal. ...

Earlier Dippy suggested I check the pin high/low -- is that what your're referring to? If so, what command do I use to check the high/low status

... There is no way out of the time limit on pulsin. If there is no pulse, it just has to sit there waiting for the pulse until it times out. The time is set in firmware at 0.65536s which just happens to be the amount of time required for a word variable to wrap.

You're confirming here that no-signal seems to be not the same as zero-pulse so far as the PICAXE is concerned. So, it seems like two independent PICAXES is the only answer if I want the strobes sequence to be unaffected by no-signal from the receiver. Or, I just live with the fact that it's not going to work properly until the transmitter is switched on.

 

[manuka]

Wreno- a great (in)site! Never mind the mid '60s, as in fact I did a SiChip article on Picaxe driving of a DSE P-9061 Futaba style servo back in June 2003, & recommended the (wired) setup. I'd just not worked with radio control of them, & assumed suitable pulses were produced at the receiver itself, rather than being sent by wireless! Thanks for the heads up... Stan

 

[Wrenow]

Stan,

It was the window of pulses that gave me the inspiration to use the encoded pulse stream as my servo delay time handler instead of the servo command for my Fire Control Assistant.

Basically the theory:

1. Read the channels I need with pulsin (in channel order, of course, since they come sequentially).
2. Do the figuring for what I want to happen.
3. Output the appropriate pulsouts to the appropriate servo(s).

Currently, I am taking 3 servo signals off the RX (2 are stripped off a "Y" connector, and are passed on) and generating one logical/conditional, modified signal for the servo controlled by the FCA. This allows the stern turret to be controlled individually unless the forward turrets traverse into its arc of fire, then control for coordinated fire automatically passes to the forward turret's control. This is all handled by an 08M on an AXE024 3 servo controller board. I use two of the servo outs as inputs (the 330R resistors are not an issue), and one of the colour sensor pins for the third input.

Allowing the TX encoder to set the control pulse interval and doing the pulse timing for a pulsout eliminates having potential timing conflicts with the servo command.

Of course, if you are not integrating it with an R/C (yes, Radio Control, not Resistor/Capacitor) system, this is not an issue.

If you ARE integrating it into an R/C system, this is something to consider. As is the entire pulse-train envelope (this becomes a severe problem if you are trying to read more than 3 or 4 inputs, do some maths, and output 4 or 5 outputs, as you generally stack the 2ms pulse windows, and when all 9 available 2ms windows are full, you have used up the entire 20ms pulse train window). Hope that makes sense to you. It kind of does to me.

As for ABENN's code under discussion:
Having not played with the code in this thread (don't have my laptop handy right this second), I am suspecting that the grief is partly due to the timing pulses being thrown into the middle of his loop in an unexpected fashion, expanding the loop, and that he is using B0, B1, and B2 as well as W1. As noted in the manual B0 and B1 are the two bytes of W0, and B2 and B3 are the two bytes of W1, so he may be getting unexpected rewrites of B2 when he writes to W1. (p.35, Sec 1 of the fine Picaxe manual) This would almost certainly further muck up results, methinks

Cheers,

Wreno

 

[abenn]

... As for ABENN's code under discussion:
Having not played with the code in this thread (don't have my laptop handy right this second), I am suspecting that the grief is partly due to the timing pulses being thrown into the middle of his loop in an unexpected fashion, expanding the loop, and that he is using B0, B1, and B2 as well as W1. As noted in the manual B0 and B1 are the two bytes of W0, and B2 and B3 are the two bytes of W1, so he may be getting unexpected rewrites of B2 when he writes to W1. (p.35, Sec 1 of the fine Picaxe manual) This would almost certainly further muck up results, methinks

Cheers,

Wreno

I wasn't aware of the relationships between the Bs and the Ws. That could explain why in the no-signal situation it's occasionally flashing the strobes, sometimes leaving one on, and sometimes no sign of life.

As I said before, I'm reletively new to PICAXE. So, what should I be using instead of w1 to prevent this conflict? I used w1 simply because that's what they used in the pulsin example in the manual Will any variable name do?

 

[Wrenow]

Dear Abenn,

Look at page 35, Section 1, of the manual. It will tell you which Byte variables are part of which Word variables. Ans which bits are incorporated in which bytes. That way you can pick and choose your variables. It doesn't much matter, I don't think, which of the available word variables (the W's) you are using for your pulsin, as long as you are not already using one of the bytes withing that word for something.

Knowing how the bits and bytes and words interrelate can make for some nifty programming tricks, but not knowing can result in unexpected glitches.

In looking at your code, it appears the highest B you are using is B2. If so, then W2 or above should be fine (W2= B5 and B4).

Cheers,

Wreno

 

[BeanieBots]

@ Stan, I don't think any of the standards have changed since WW2.
The only real change is the size and quality of the electronics. My license (yes, you used to need one of those) states "no spark sending apperatus whatsover" which still stands
7 channels used to be the most but now 9 is common. Many have more but they multiplex channels to achieve it with the sacrifice of response.

@abenn
A good receiver will give a flat voltage (0v) when the transmitter is off.
If however, there is a lot of radio noise, the pulses could be outside the normal range.
Testing for outside range (as you do) will take care of that, but NO PULSES (pulsin = 0) is a special case because it causes pulsin to timeout. All other pulses will always be less than 20mS (reset by next channel in worst case)which should not effect your loop in the same way that no pulses will do.

The use of b's that are also used w's is undoubtedly what is causing the hang as has already been pointed out.
If you put your landing gear code at the end of the main loop (as suggested earlier) and make a specific test for zero pulse, then you should be able to get the desired effect.
It is possible to use a variable in the pause statement. You could adjust the value of that variable depending on the pulsin value to keep the strobe timing constant with a special case for zero pulse.

 

[Wrenow]

Abenn,

Also keep in mind that it is virtually universally recommended to turn the transmitter on before powering up the RX or model, and to power the TX off last. Lots of R/C reasons for that, by the way. In fact, a lot of R/C electronics will failsafe out if you fail to have the TX on when you power the RX.

If you follow the recommended good practice, you should only encounter a no signal condition on LOS failure. And, many modern RX's have programmable LOS failsafe modes built in (the little $25 Lepton has 2 or 3 standard failsafes and one programmable).

Just something to keep in mind about your intended environment.

Cheers,

Wreno

 

[abenn]

Thankyou Wrenow and Beanibots: I've read the "General Purpose Variables" in my copy of the manual (it's page 28 in mine) and seen the relationship between w's and b's, but I didn't appreciate (a) that those are the only variables you can use or (b) that using one of the w's effectively means that you've used up two of the b's

My receiver is PPM, so doesn't offer a failsafe setting facility. If I want to check for a 0-volt situation, is readadc,3,variable the appropriate command? Or will it cause other problems by triggering between pulses when, presumably, the voltage is also zero?

 

[BeanieBots]

I honestly don't think there is any other simple method than pulsin and specifically testing for timeout to detect "no pulses".
You could only use ReadADC if you had a way of syncronising the read with the intended timeslot of the missing pulse. Not impossible but far too complex to be a serious option for what really is a simple task.

Go back to basics and get something simple working first.
Try this (untested code) that should make an LED flash every second and turn a second one on depending on the RC signal.

main:
pulsin RCpin,w0
if w0=then NoPulses
if w0 < 150 then
high Led2
else
low Led2
endif
pause 653
NoPulses:
Pause 400
toggel Led1
goto main

The only other option but not very good if you want to do much with the signal, is the one proposed by Dippy.
You would need to create two loops which each test the input state and increment a counter. One tests when high, the other tests when low. Each tests the counter after each increment and takes appropriate action. What the values for "action" would be will require experimentation because it would depend on your clock speed and where the code resides in the PICAXE. That is, it differs every time you change the program. A command takes ~250uS at 4Mhz so you should get a few counts for a 1mS pulse if the loop is very tight. Probably better to run at 8Mhz.

 

[abenn]

OK, thanks BeanieBots At least I've got a program that works exactly as I want so long as there's a valid pulse from the receiver, so I think I'll settle for that. Absence of a proper strobe pattern will at least prompt me to switch my transmitter on

I was interested to see your if ... else ... endif routine: I'm familiar with it from my (limited, many years ago) Basic and (current) dBase programming, but it's not in the PICAXE manual of Basic Commands. Also I noticed in another post someone had used case ... endcase; so the PICAXE can recognise most or all Basic language -- not just the commands that are in the manual

 

[Wrenow]

T

My receiver is PPM, so doesn't offer a failsafe setting facility. If I want to check for a 0-volt situation, is readadc,3,variable the appropriate command? Or will it cause other problems by triggering between pulses when, presumably, the voltage is also zero?

Abenn,

I was assuming a PPM RX. Be aware that many modern PPM RX's have DSP, anti-glitch, and failsafe programming. The Sombra Labs series certainly does, I believe Polk's Hobbies does, some of the new 2.4GHz stuff form Horizon/Spektrum does. I seem to recall some Castle/Berg doing so. I believe Micron DIY RXs having a DSP decoder with this feature as well. Even some of my cheap little Futaba 3 channel 75Mhz car RXs have programmable (to a degree) failsafes.

Just so everyone is on the same page, there are frequently 2 or three selectable failsafe modes:

1. Output last known good data for about 1.5sec (or other period), then go dark (leaving servos where they were and causing ESC's to power down after their timeout).
2. Output last known good data forever until signal reestablished.
3. Send servo signals to predetermined failsafe position.

Cheers,

Wreno

 

[BeanieBots]

Abenn, there was a large amount of new commands added a long time ago now which included if/then/else select/case etc.
It's all in the LATEST manual. If you have an old version of the editor, then you must enable the enhanced features via the options panel to use them.

If you don't have these, then update your editor. You really are missing out without them.