General discussion relating to the library modules supplied with the compiler
Moderators: David Barker, Jerry Messina
-
gramo
- Registered User
- Posts: 200
- Joined: Tue Mar 20, 2007 6:55 am
- Location: Australia
-
Contact:
Post
by gramo » Fri May 11, 2007 12:59 pm
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
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
-
Contact:
Post
by David Barker » Fri May 11, 2007 2:27 pm
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
- Registered User
- Posts: 200
- Joined: Tue Mar 20, 2007 6:55 am
- Location: Australia
-
Contact:
Post
by gramo » Sat May 12, 2007 12:19 pm
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
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
-
Contact:
Post
by David Barker » Sat May 12, 2007 12:33 pm
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
- Registered User
- Posts: 200
- Joined: Tue Mar 20, 2007 6:55 am
- Location: Australia
-
Contact:
Post
by gramo » Sat May 12, 2007 12:44 pm
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
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
-
Contact:
Post
by David Barker » Sat May 12, 2007 1:01 pm
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
- Registered User
- Posts: 200
- Joined: Tue Mar 20, 2007 6:55 am
- Location: Australia
-
Contact:
Post
by gramo » Sat May 12, 2007 1:07 pm
David Barker wrote: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
- Posts: 262
- Joined: Wed Oct 04, 2006 7:25 am
- Location: London UK
Post
by TimB » Sat May 12, 2007 2:20 pm
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
- Registered User
- Posts: 200
- Joined: Tue Mar 20, 2007 6:55 am
- Location: Australia
-
Contact:
Post
by gramo » Sun May 13, 2007 12:38 am
That makes sense, thanks for explaining it further for me