wireless communication

[MrDEB]

I still like the 7555 idea.
It outputs a pulse train just as dougy shows or at least similar.
If it is set up with a wide range between the two switches then say switch one has 20K pulses and switch two has 10K pulse.
The receiving pic just times the number of pulses within say 250ms.
If say a couple of hundred pulses are missed, no big deal.
At least thats my thoughts.
Transmission range is only 5-8feet max.
I have the TX and RX kit, a 555, a pic time to experiment

 

[dougy83]

I still like the 7555 idea.

Then go for it; it will be fine.

 

[Nigel Goodwin]

A nice idea, but I'm not sure how much help that will be; you still need a method of extracting the 0x55 or else you won't be able to detect the start and stop bits of the characters

That's one of the things Manchester (and other commercially used systems) does, send a preamble before the actual data.

 

[Nigel Goodwin]

New tutorial boards

OK, as I mentioned, I ordered a couple of nRF24L01 modules, which arrived yesterday, so I've knocked up a couple of tutorial boards for a forthcoming addition to my PIC tutorials. I've just done a quick scan of them, and the page currently just holds that:

 

[Mr RB]

Nice work Nigel, i take it those TO-92 devices are 3.3v 3-pin regulators?

How did you find itead company to deal with? I have thought of ordering from them as they have some cheap stuff, but never got around to it.

Re Dougy's simple serial-transmit what about sending a "correction" byte first, rather than a 0x55 maybe a byte that has the first x bits low, to provide a fast AC correction. It should be easy enough to test with differen bytes and serial and still gives that benefit of balancing the AC, and send/receive all done with UART no problems. I think I have seen something in the past that did that exact method so it can't be too original.

 

[Nigel Goodwin]

Nice work Nigel, i take it those TO-92 devices are 3.3v 3-pin regulators?

Yes, LP2950-3.3

How did you find itead company to deal with? I have thought of ordering from them as they have some cheap stuff, but never got around to it.

I ordered from an EBay shop based in the UK, I ordered Saturday night, they were dispatched Monday, and I received them Tuesday morning - the post is excellent here.

Re Dougy's simple serial-transmit what about sending a "correction" byte first, rather than a 0x55 maybe a byte that has the first x bits low, to provide a fast AC correction. It should be easy enough to test with differen bytes and serial and still gives that benefit of balancing the AC, and send/receive all done with UART no problems. I think I have seen something in the past that did that exact method so it can't be too original.

The problem is reliability - the output pulse widths from the receiver aren't consistant, they vary with signal strength etc.

This is why commercial systems use Manchester coding, it cures all the problems with wireless communication as the pulses widths don't matter.

 

[Mr RB]

...
This is why commercial systems use Manchester coding, it cures all the problems with wireless communication as the pulses widths don't matter.

Yeah I knew that.

Mainly I was thinking for people determined to "just use the UART" or who already had a project just using the UART, if a single byte coule be sent first to manually compensate some of the issues with the AC coupled data and provide an improvement for practically no cost.

Using manchester and a preamble costs datarate and really adds a lot of complexity and hassle to the firmware, in a world where spoilt kids now all expect every micro to have a UARTmodule and just write a byte to it, and it does everything for them including wipe their butt.

 

[Nigel Goodwin]

Yeah I knew that.

Mainly I was thinking for people determined to "just use the UART" or who already had a project just using the UART, if a single byte coule be sent first to manually compensate some of the issues with the AC coupled data and provide an improvement for practically no cost.

You've got the cost of the hardware inverters each end, unless you've got a controller with it built-in (as some recent PIC's do). In that respect Manchester is cheaper, as there's no actual 'cost'.

Using manchester and a preamble costs datarate and really adds a lot of complexity and hassle to the firmware, in a world where spoilt kids now all expect every micro to have a UARTmodule and just write a byte to it, and it does everything for them including wipe their butt.

But it makes it work correctly

It also doesn't 'cost datarate', because you can run a far higher datarate, using an inverted UART you have to cripple the datarate until it manages to work ''reasonably' reliably. Manchester is inherently half the maximum speed (plus preamble etc. - which loss varies with packet size) - but UART won't get anywhere near half the potential speed, back when I did it you needed to drop to at least 1/4 speed, and 1/8 would be more reliable.

 

[be80be]

These transmitters and receivers use OOK "on-off-keying" which send digital data so really if their close the noise shouldn't make a big deal.

They use this to turn on and off runway lights at airports. So it really boils down to to output power as long as it's greater then the noise you would be fine. But like Nigel been saying if noise is high you'll need incodeing.

 

[Nigel Goodwin]

These transmitters and receivers use OOK "on-off-keying" which send digital data so really if their close the noise shouldn't make a big deal.

You've not been paying attention!

It's not specifically noise that's the problem, it's the fact that wireless modules don't provide the same width pulses on the output as you provide to the input (and neither does IR).

They use this to turn on and off runway lights at airports. So it really boils down to to output power as long as it's greater then the noise you would be fine. But like Nigel been saying if noise is high you'll need incodeing.

I'm pretty sure they will use Manchester coding (or similar) for switching aircraft lights ON and OFF, they certainly won't use crude and unreliable RS232 type signals via wireless. Although I would imagine they would use wires in preference to radio anyway?.