quote:

---

Originally posted by DumHed:

quote:

---

Originally posted by NMO:
I discovered the out by 20 problem

Yeah I remembered that, but this is a similar problem in a completely different place. - I'm reading a serial data stream, and the byte value I receive is different to the one I transmit!

I'll need to set up some extra monitoring at each end and see where the values go funny.

---

---

yeah, as mentioned this is a completely separate issue.

It's a serial data stream, nothing to do with the pulsin command or any timing measurements.
The value is a byte, being stored in a byte register, and it receives the previous byte perfectly.

My original PWM controller code used b0 for the pulsin (cos I copied it from Aaron ), but the way I was using b1 meant that even if it was trashed by a pulse value of over 255 I re wrote it before I needed to read it.
I changed that to a word register later just to make sure it was being done 100% properly
_________________
The Engine Whisperer - fixer of things

ok this serial problem is really strange!!

Basically I'm sending out a serial data stream from the TX that has an address byte followed by channel data for each of the three channels, then the RX is using the SERIN command with the filter containing the address byte value for the channel it needs to decode.

The idea is that SERIN waits for the address byte, then grabs the next byte and saves that in a variable for the channel data.

TX:

code:

---

SEROUT 0,N2400,(1,chan1,2,chan2,3,chan3)

---

code:

---

SERIN data_in,N2400,(addr),stream

---

did you try swearing at it?
_________________
www.demon50s.com - Minimoto parts
http://www.youtube.com/user/HyzerGlen - Videoooozzz

not yet!!
you might be on to something there

I'm really getting the feeling that the RF modules and the PICaxe's rather basic serial handling is the problem.

I'll give it a go using a pulse train type setup like conventional R/C gear uses and see how that goes.
At least that way it can't get stuck waiting for data, and it'll work with pretty much any type of radio / IR link (spark gap transmitter!)
_________________
The Engine Whisperer - fixer of things

might be worth asking over at the picaxe forums - http://www.rev-ed.co.uk/picaxe/forum/

I doubt the serial input routines would be that buggy, they've been used in some prety complex projects that I've seen and havent heard mention of that type of problem, you never know though..

How about just writing a from-scratch very simple serial echo routine into it to test the serin & serout commands. Sometimes if I get stuck on a weird bug, I'll do that sort of thing to eliminate all the other possible causes from other areas of the code.

Dont use any bits of code from your earlier program, or you might take some obscure bug with it. Helps you figure out things on occasion.

Let us know when (if ?) you find it.
_________________
Great minds discuss ideas. Average minds discuss events. Small minds discuss people

If your inteneding on using the servo command to drive a speed comtroller in your receiver I may have found a solution to serin getting stuck. It appears as though there is only 1 timer built into the picaxe as I have noticed that while the serin command is running the servo command stops. hence if the serin commandf gets stuck i9n it's endless loop it'll failsafe the IBC.

hehehe, well that's kind of funny really - kind of solves its own problem if you're driving servo outputs

Brett: all this is being looked at in a simple serial echo routine. I haven't had this version driving any sort of outputs or doing any other processing yet.

I had the serial link controller working before, but it had the values offset by 27, and I was just adding 27 to fix it.
With this version I can't just add to it because it's still staying within my channel value limits, so I'd never be able to get full reverse.

In the end, I think there are timing issues that will prevent this from being a reliable solution, so for now I will go to the pulse train system.
The idea of this is to make something that's reliable, and based on cheap and easy stuff to get.
I'm sure it'd work well using more expensive serial RF modules, PICs running on proper crystal oscillators and using hardware UARTs, but I like the idea of making it work with the simple stuff
_________________
The Engine Whisperer - fixer of things

One thing that could cause droping of bits is if the Picaxe internal resinator is not running at the correct frequency 4MHz. I haven't played with serial commands much so I don't know if it would work or not.

you could try using the following command to correct it.

calibfreq

Syntax:
CALIBFREQ {-} factor

- factor is a constant/variable containing the value -31 to 31

Function:

Calibrate the microcontrollers internal resonator. 0 is the default factory setting.
Information:

Some PICAXE chips have an internal resonator that can be set to 4 or 8Mhz
operation via the setfreq command.

On these chips it is also possible to ‘calibrate’ this frequency. This is an advanced
feature not normally required by most users, as all chips are factory calibrated to the most accurate setting. Generally the only use for calibfreq is to slightly adjust the frequency for serial transactions with third party devices. A larger positive value increases speed, a larger negative value decreases speed. Try the values -4 to + 4 first, before going to a higher or lower value.

Use this command with extreme care. It can alter the frequency of the PICAXE
chip beyond the serial download tolerance - in this case you will need to perform
a ‘hard-reset’ in order to carry out a new download.

The calibfreq is actually a pseudo command that performs a ‘poke’ command on
the microcontrollers OSCTUNE register (address $90).

When the value is 0 to 31 the equivalent BASIC code is

poke $90, factor
pause 2

When the factor is -31 to -1 the equivalent BASIC code is

let b12 = 64 - factor
poke $90, factor
pause 2

Note that in this case variable b12 is used, and hence corrupted, by the
command. This is necessary to poke the OSCTUNE register with the correct value.
_________________
It's all about the destruction.

It would be good if we can get reliable serial data going, as then it may be possible for 2 people to operate on the same frequency. IE your using qualifiers 1 2 3 If I used qualifiers A B C or something else then in teory your receiver wouldn't respond to my transmission. Don't worry though I'm not trying to invade your use of 433.92 Mhz

since both would be transmitting at the same time I think the result would be no one being able to receive anything cos the data will be corrupted.

I think serial data can be done, bit the PICaxe is maybe not the chip for it.

Ajax: I'm sure some tweaking of the clock would help, but in the end I need these things to have a fair bit of "give" to work reliably, and they'll be exposed to all kinds of temperature changes, electrical noise, and multiple chips will be used.
I could do some sort of auto calibrate program (serial echo and tweak the clock up and down till it gets the right values) but I think it's still going to be too touchy.

In other news, my pulse train style system is working pretty nicely, so now I just need to get it doing PWM (basically mean un commenting a bunch of stuff) and do some range testing

Interestingly, when using the RF link all pulses end up about 50us longer than they do when using a short cable.
That's probably part of the serial issue, but it's a lot easier to correct in this setup.

Also, feel free to also use 433MHz.
I'll be looking into other frequencies once I have it working.
I'm thinking of modifying a 2.4GHz video transmitter / receiver set to see if I can send pulses or data over that.
They tend to have selectable channels too.
_________________
The Engine Whisperer - fixer of things

If you want to i have some 16F628A's running in serial mode you could try
_________________
Mechanical engineers build weapons, civil engineers build targets

quote:

---

I'm thinking of modifying a 2.4GHz video transmitter / receiver set to see if I can send pulses or data over that.

---

yep, those are the ones I'm thinking of, but I also have a pair of similar ones at home I might hack up.

I have a feeling they need a composite video sync to do anything much, but it might be possible to connect further down the signal stream.

They also transmit two audio channels over the same connection.

Anyway, the pulse train sending system is working nicely now, and the hardware watchdog system also seems to be the go.
With the transmitter turned off I get a false good signal about every 15-30 seconds, which won't be enough to enable the hardware watchdog, so it should all work nicely
_________________
The Engine Whisperer - fixer of things

I got basically all my software working, so today I made up PCBs for a bunch of stuff.

Transmitter board:
This fits inside a cheap 2 channel radio, using the original board mounts, control sticks, switches, and battery holder.
One of the old channel reverse switches is now used to enable mixing to drive tank control.
There are connections for two different types of RF module (the cheap Jaycar one, and a super high quality FM 433MHz module I had at work)

Receiver board:
There's one of these needed per channel, and they connect together to take the same pulse stream from the RF module.
I've designed this so the same board can be used for my radio system, or for traditional servo inputs, with a quick software reload.
I have some ideas for these that will allow them to do mixing, or have gyro inputs (from a $10 gyro module) so a complete controller for two motor channels will require two of these boards and two of the power control boards.

RF module board:
I made up a small PCB to hold one of the FM RF modules I'm using, to make it easier to connect to.
The Jaycar modules connect directly to the receiver boards very easily.

PWM and relay reverse board:
This is an opto isolated board containing 4 MOSFETS, 3 for PWM control of the motor, and 1 to switch a couple of horn relays for reversing.
I could probably go for a smaller transistor for the relay control, but this way means less different parts are used, and it'll handle any size relay(s).
I'll also make a full MOSFET H-bridge board with the same interface once I have a better look at the driver chip options.

Mixer:
I made a mixer program for the PICaxe so I figured a super tiny mixer module could be handy for some people.
It's about as small as possible, with two inputs, two outputs, the PICaxe, and a bypass capacitor.
I haven't tested this yet, but there's no reason why it won't work


So, tomorrow I'll make up the rest of the boards and test them out.
I'm looking forward to having a completely custom control system in my robots!

I have a few more ideas to try out too, with some gyro / accelerometer stuff, and I want to do a fully mixed two channel relay controller using one PICaxe, to work from my transmitter - for possible use in other bots like Woktronix.
_________________
The Engine Whisperer - fixer of things