Manchester.Read

[gramo]

Any chance of getting a function like the following in the future?

Code: Select all

Dim Data(2) As Word

Data = Manchester.Read(Data(0), Data(1), Data(2))

As there is really no point to use the USART to receive Manchester Encrypted data, as it would not only be subject to exactly the same downfalls, but also twice as often. eg;

0101 in Manchester = 10011001

[David Barker]

Use the manchester library to encode a decode data (from any source)

Code: Select all

function Encode(pValue as byte) as word
function Decode(pEncodedValue as word, byref pDecodedValue as byte) as boolean

[gramo]

But you aren’t getting the full advantage of receiving Manchester encoded data, your simply increasing the chance of corruption by two fold

Manchester code is a code in which data and clock signals are combined to form a single self-synchronizing data stream; each encoded bit contains a transition at the midpoint of a bit period, the direction of transition determines whether the bit is a 0 or a 1

Receiving the encoded data via UART would not in any way be receiving Manchester data in its true form, but it would be a UART interpretation of Manchester encoded data...

Consider this encoded binary number transmitted via UART "0110". If you connected it to the UART RX on another device, you do not gain any of the benefits of encoding it to start with, if anything, you are increasing the error rate two fold!

By all means, I could be wrong, just my spin on things

[David Barker]

I'm aware of how manchester encoding works.

You keep mentioning USART, but the routines in the manchester module have nothing to do with how the data is transmitted. It just encodes an 8 bit value into a 16 bit manchester encoded value or decodes a 16 bit manchester encoded value back to its original 8 bit form.

How you send and receive the data is entriely up to you...

[gramo]

That's where I'm heading with this thread
Sending the encoded data is no problems with UART, but there's no point in receiving the data the same way


Would it be possible to extend the Manchester library so that you can have a software Manchester receive routine. eg;


Consider the data sent to the following PIC would be 1010101001010101

Code: Select all

Dim Data As Byte

Manchester.Init(PORTC.0, 9600)       // Sets input pin to PORTC.0, and buad to 9600

Data = Manchester.ReadByte

Data would now contain the binary number 00001111

Now you could actually make full use of the routine, as the Manchester.Decode function doesn’t lend its self much use for most (all) applications without some sort of actual Manchester Receive routine

[David Barker]

The decode routine is useful! - I've used it myself in a commercial application quite recently (RF) - earned £££ - so I would have to disagree when you say 'doesn’t lend its self much use for most (all) applications'

For me, I just encode the data then TX (using a medium of your choice) -> RX then decode. Unless you want to get into hardcore RF, I find this approach the simplest.

If you want to roll your own routine, just use the encode/decode source as a template...

[gramo]

The decode routine is useful! - I've used it myself in a commercial application quite recently (RF) - earned £££ - so I would have to disagree when you say 'doesn’t lend its self much use for most (all) applications'

For me, I just encode the data then TX (using a medium of your choice) -> RX then decode. Unless you want to get into hardcore RF, I find this approach the simplest.

If you want to roll your own routine, just use the encode/decode source as a template...

Fair enough. I thought there would be no point to physically receiving the encoded data without using the direction of transition to determine what each bit is, irrespective of the medium.

You may as well not encode/decode the data at all, and leave it in its raw form, as when encoded, you’re simply doubling the length of the data to be sent/received via whatever medium...

[TimB]

Manchester is only used to keep the data slicer balanced in the RX unit. To do that there is always an over head. Another method is to use symbol encoding. Manchester = 16 bits per byte Symbol = 12 so a 1/4 saving.

With rf once it's latched on the difference between good data and bad data is very small, a few meters more and you start to lose the signal quality and to retrieve the data from a bad signal is very hard.

The basic rules are
1 preamble
2 Sync
3 keep the data balanced unless your only going to send 1 byte
4 use a CRC
5 send it a few times
6 on the RX end dedicate a cpu to it.

After that then start on complex rf code with error detection, I personaly spent months perfecting my symbol encoding routines.

I have seen some very nice rx products from hoperf http://www.hoperf.com/doce/

They have all the decoding stuff built in on some models

[gramo]

That makes sense, thanks for explaining it further for me