Shop OBEX P1 Docs P2 Docs Learn Events
Propeller DEMO : (14.5 Meg Baud) High Speed Prop-to-Prop Serial Communication — Parallax Forums

Propeller DEMO : (14.5 Meg Baud) High Speed Prop-to-Prop Serial Communication

Beau SchwabeBeau Schwabe Posts: 6,545
edited 2010-12-25 12:29 in Propeller 1
NEW 12/12/2007
14.5 Meg Baud Upgrade



Ok, beta testers... I have run this DEMO and tested over 100 Billion data Bits with no Transmission Errors over the distance of 10 feet from one Propeller to another Propeller.
Here is a beta release before I place it in the object exchange. ...· Enjoy!!

attachment.php?attachmentid=50683


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 12/12/2007 6:27:49 AM GMT
«1

Comments

  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2007-11-28 23:28
    Wow... This will see some action on my desk soon!

    I'm picturing two props linked by their propplug port with a slightly modified cdrom audio cable... heh..

    Thanks for this!

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Just getting started with Propeller?

    Propeller Cookbook

    PropDOS
  • David CuthbertDavid Cuthbert Posts: 12
    edited 2007-11-29 08:03
    Looks nice!

    One question: did you have the two props running off the same clock, or were they using independent clocks? If they're using independent clocks, drift may become an issue with this circuit. Assuming 1% drift, you might be out of phase by 34 ns by the time you reach the stop bit. That will be more than the 25 ns margin you have from the starting edge (actually less, since there's a sampling setup time involved).

    If it's possible to skew the sampling by one cycle so you're in the middle of the bit, that would give you more margin.
  • Bill HenningBill Henning Posts: 6,445
    edited 2007-11-29 08:31
    Very cool Beau, that is actually 10mbps raw data rate.

    I was thinking of something similar earlier, but with only one start bit, and more than one 32 bit word before the stop bit smile.gif

    Hmmm... two waitpne's in a row should take 10 cycles, positioning the "sampling point" right in the middle of 100ns bit cells... smart!

    I even considered a faster version, where a long would be compiled into a series of set/clear tx bit, that way a 20mbps data rate can be achieved for transmission; and a wasteful sampling of one bit to cog long would also allow 20mbps reception.

    David, I would not worry - even if both crystals/oscillators had 100ppm error, worst case error would be 200/5000000 which means you'd have to have 25,000 consecutive bits before you drifted one bit cell worth.
    Beau Schwabe (Parallax) said...

    Ok, beta testers... I have run this DEMO and tested over 100 Billion data Bits with no Transmission Errors over the distance of 10 feet from one Propeller to another Propeller.
    Here is a beta release before I place it in the object exchange. ... Enjoy!!



    attachment.php?attachmentid=50683


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com - a new blog about microcontrollers
  • rjo_rjo_ Posts: 1,825
    edited 2007-11-29 15:05
    Beau,

    I am trying to figure out the practical implications of this data rate... for instance does 8.42 Mega baud mean that I need 4 lines connecting two Props to transfer raw data at NTSC rates?

    A bit off topic, BUT my RadioShack got a shipment of Parallax parts yesterday... in about 20 seconds I had my new Memsic 2125 running your demo code. (I'm still trying to figure out if I can separate tilt and acceleration without anything else[noparse]:)[/noparse]




    Rich
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-11-29 16:33
    David Cuthbert,

    Thanks David

    The Props are running off of independent clocks. ...And sampling does happen in the middle of the "instruction" bit (see below).· At 10 feet of ribbon cable the signal did not appear to show any significant "edge-rounding" due to capacitive/resistive effects of the cable. Within roughly 10nS, any edge distortion had stabilized to one rail or the other. I consider an unshielded, 10 foot connection to be excessive, and your signal will only improve with closer, shielded connections.

    The tolerance of the 5MHz crystal on the Propeller is +/- 30 PPM which translates to +/-480 PPM after the X16 PLL. Even at 80MHz, an error of +/-38,400 (<-- 480 PPM X 80 = 38,400) pulses is better than 0.001% error. If each LONG transmission takes 3800nS that's 304 Clocks (<-- 3800nS / 12.5nS = 304 Clocks) ... multiplied by a 0.001% error, that's 0.304 or approximately 1/3rd of a single clock pulse.



    Bill Henning,

    Thanks Bill

    "Hmmm... two waitpne's in a row should take 10 cycles, positioning the "sampling point" right in the middle of 100ns bit cells... smart!"
    You get the idea, but it's not in the center of the 100nS bit cells.... break up the 100nS Bit Cells so that 50nS samples the bit, while 50nS Shifts and rotates the value into the Buffer.
    In the first 50nS, the sampling is in the middle because of the 2 cycle offset (2 x 12.5nS = 25nS) of the 10 cycles required from the·waitpne and waitpeq instructions.

    "I even considered a faster version, where a long would be compiled into a series of set/clear tx bit, that way a 20mbps data rate can be achieved for transmission"
    I thought of something like that as well, but the overhead time required to read, and self modify the code to allow 50nS transitions would not allow the same "packet speed"·as I am currently achieving. (1k Longs in approximately 4mS)


    rjo_,

    Thanks Rich

    The 8.42M baud is not a continuous data stream,· it is sent in·bursts much like standard Serial practices.· I·Suppose that you could use 4 COGS pointing to different memory address ranges for a burst throughput of 33.68 MHz.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.

    Post Edited (Beau Schwabe (Parallax)) : 11/29/2007 5:19:58 PM GMT
  • BaggersBaggers Posts: 3,019
    edited 2007-11-29 17:23
    Nice work Beau, that's pretty neat,

    Just out of curiosity, as I've wanted to ask a few things like this, but what about temperature changes etc, would any external effects change the accuracy?
    Cos I've·been·thinking about a byte burst data mode, for propgfx too.

    rjo_ you could always wait til prop2 and do it at double ntsc speed, in a year or two [noparse]:)[/noparse]

    Post Edited (Baggers) : 11/29/2007 5:28:59 PM GMT
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-11-29 18:34
    Baggers,

    Ok, so this is an extreme... While one Prop was at room temp, I held a lighter·to the crystal of the other Prop until it was too hot to touch... still no packet errors.

    Note:· It doesn't account for any temperature variations of the Prop itself though... but if the time base remains stable, then so should the rest as long as the code is·able to run.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • BaggersBaggers Posts: 3,019
    edited 2007-11-29 19:50
    Cheers Beau, hope you didn't burn your fingers in testing that for me [noparse]:o[/noparse]

    Nice one though [noparse];)[/noparse]
    as I was thinking of doing an 8bit data burst mode, in transfering data to the PropGFX, and as you've used different clocks for both props, then I'll take that as it's a pretty secure way to do it [noparse];)[/noparse]
    Should get a decent amount of data throughput with 8bit transfers [noparse]:)[/noparse]

    Oh, another question for you Beau, or anyone in the know for that matter.
    RDLONG takes 7+ cycles, say 7 for example, eg, it caught it when the hub was ready for it.
    then doing an ADD would add another 4
    and a DJNZ back to the RDLONG would add another 4... would that then make the RDLONG hit 7 cycles? or would it be more?

    also more code inbetween rdlongs, eg
    RDLONG blah2,blah
    ADD blah,#4
    MOV OUTA,blah2
    ' where you would now be allowed a RDLONG ( if above question is correct at 7 cycles )
    mov something,else
    xor justtobe,different
    ' these two instructions above would be replacing your allocated hub slot
    sub onefrom,theother
    add thisto,that
    ' two more instructions for padding again, then
    RDLONG blah2,blah
    ' would this RDLONG take 7 cycles, or would it be different, since the two replacement ones ( mov and xor ) would have taken 8 cycles, and not 7. ?

    Hope you can clarify this for me,
    Cheers.
    Baggers.
  • rjo_rjo_ Posts: 1,825
    edited 2007-11-30 03:00
    Baggers,

    By next year I'm going to want HD not NTSC[noparse]:)[/noparse] There is a LunarXprize with our names on it[noparse]:)[/noparse]

    So, what we do now for NTSC... will work later for HD. Either way, you are going to have to get cracking on this, I have already started spending the money.

    Rich
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-11-30 20:45
    Baggers,

    Take a look at this link to answer some of your questions...

    http://forums.parallax.com/showthread.php?p=692360

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • BaggersBaggers Posts: 3,019
    edited 2007-11-30 22:17
    Thanks Beau, that answered my questions [noparse]:)[/noparse]

    Cheers,
    Baggers.
  • David CuthbertDavid Cuthbert Posts: 12
    edited 2007-12-02 02:07
    Thanks, Beau! Good to know you've looked into the drifting and whatnot.

    The last time I designed a comms circuit was years ago; we had to have clock recovery, 8b/10b encoding, etc., and were stressing a lot of components beyond their limits. (It was a technology feasibility demonstration... lots of one-offs and such which never would have worked as-is for mass production!)
  • simonlsimonl Posts: 866
    edited 2007-12-04 10:24
    Hi Beau,

    Tried to get this working last night but, alas, nothing I tried was error free - in-fact I was very lucky if I got only about 25% errors!

    My set-up:
    Prop1: PropStick with 5MHz xtal acts as Tx.
    Prop2: Prop' on breadboard with 10MHz xtal acts as Rx. This has TV attached - I modified your code to work with TV_WText, and changed the clk/freq settings to
    _clkmode = xtal2 + pll8x
    _xinfreq = 10_000_000
    
    


    I tried Tx/Rx connection using a) 10cm jumper wire, and b) 1.5m Cat5e cable.

    Observations:

    1. With no wire connecting Tx - Rx I was seeing error count increment by one approx. every 1sec.

    2. With Tx/Rx connected, errors incremented much faster.

    3. I tried different waitcnt values (line 86 in Tx), but this only appeared to affect the rate of error incrementing!

    4. Tx/Rx connection using Cat5e cable produced faster error increments than the short jumper wire.

    I've attached copies of the code I'm using (if I've done it right!), in case anyone else wants to try this with TV. <edit> Updated to fix unequal buffers and waitcnt. </edit>

    I'm guessing that the problem's down to the mis-match of xtals? Gave up trying at 02:00 this morning (!), but will try again with another 10MHz xtal'd Prop' this evening.

    What would be the best way to add some flow control?

    Anyways; great work smile.gif I'm hoping it'll form the basis of a token-passing ring set-up eventually (but I guess you're already working on multi-prop comm's & protocol yourself!?)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,

    Simon
    www.norfolkhelicopterclub.co.uk
    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
    BTW: I type as I'm thinking, so please don't take any offense at my writing style smile.gif

    Post Edited (simonl) : 12/4/2007 5:05:19 PM GMT
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-12-04 15:19
    Do you have the GND's connected together between the Propellers?
    (TX) P0  >----------------------> P0 (RX)
    (TX) GND >----------------------> GND (RX)
    

    Also, if your·setting the clock this way·on one Propeller, it should probably be set the same way on the other Propeller
    _clkmode = xtal2 + pll8x
    _xinfreq = 10_000_000
    
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • simonlsimonl Posts: 866
    edited 2007-12-04 15:25
    Hi Beau,

    Yup - GNDs connected.

    Not sure I understand the 2nd point; my Tx Prop has a 5MHz xtal, so setting _clkmode & _xinfreq as above wouldn't be valid, would it?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,

    Simon
    www.norfolkhelicopterclub.co.uk
    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
    BTW: I type as I'm thinking, so please don't take any offense at my writing style smile.gif
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-12-04 15:29
    Simon,

    In the TX... the waitcnt(800+cnt)· ... should be much higher ... I originally used .... waitcnt(800_000+cnt)

    I'm scoping the signal·right now... I will look into it

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • SapiehaSapieha Posts: 2,964
    edited 2007-12-04 15:34
    Hi simonl.

    Why you have diferent Buffer sizes on TX/RX ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.

    Sapieha
  • simonlsimonl Posts: 866
    edited 2007-12-04 15:40
    Beau / Sapieha,

    I'm pretty sure I had 800_000 and equal buffer sizes during testing - but then it was in the early hours...

    I'll be sure to try again tonight.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,

    Simon
    www.norfolkhelicopterclub.co.uk
    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
    BTW: I type as I'm thinking, so please don't take any offense at my writing style smile.gif
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-12-04 15:45
    Simon,

    I double checked...

    The file you posted has 800 instead of 800_000 ... with your TV modification and 512 Packets on the receive side, the minimum number without generating errors seems to be about 520_000.


    Sapieha,

    I thought that this was odd also... However, as long as the TX is sending more packets than the RX is receiving you should be ok. The "extra" Packets in this case are simply ignored.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • simonlsimonl Posts: 866
    edited 2007-12-04 15:50
    Hi Beau,

    Yeah, I _think_ that's just because I didn't save the versions in step (oops!), but I'm sure I had them in step during testing - I'll try again tonight.

    As for the _xinfreq & _clkmode; I've used those settings OK on previous object tests, but do you think that might be causing bit sync problems?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,

    Simon
    www.norfolkhelicopterclub.co.uk
    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
    BTW: I type as I'm thinking, so please don't take any offense at my writing style smile.gif
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-12-04 15:59
    Simon,

    Probably... I did have a 10MHz·around here somewhere, but I can't find it at the moment.

    Edit :

    Test1 - TX=10MHz RX = 5MHz - tested OK

    Test2 - TX=5MHz RX = 10MHz - tested OK




    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.

    Post Edited (Beau Schwabe (Parallax)) : 12/4/2007 4:52:01 PM GMT
  • simonlsimonl Posts: 866
    edited 2007-12-04 16:56
    Hmmm, OK; what did you use for _xinfreq & _clkmode?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,

    Simon
    www.norfolkhelicopterclub.co.uk
    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
    BTW: I type as I'm thinking, so please don't take any offense at my writing style smile.gif
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-12-04 17:56
    simonl,

    "Hmmm, OK; what did you use for _xinfreq & _clkmode?"

    The same settings you had... Attached is a modified version of the code you sent for both RX and TX.
    From the time I started it about an hour ago, it's reached over 2.5 Billion Bits with no Errors.




    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • simonlsimonl Posts: 866
    edited 2007-12-04 21:48
    Thanks Beau, I'll give that a try when I get back home in an hour.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,

    Simon
    www.norfolkhelicopterclub.co.uk
    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
    BTW: I type as I'm thinking, so please don't take any offense at my writing style smile.gif
  • simonlsimonl Posts: 866
    edited 2007-12-05 10:26
    YAY - it works without errors! Woohoo smile.gif

    Turns out that it's the PC to Prop' connection that caused the errors! I discovered that if I touched the DB9 connector everything started working, so I disconnected the PC serial cable and all's fine.

    Does anyone know why this might be? I'm guessing it's something to do with earthing, but haven't a clue why.

    My set-up:

    Mains - 4-way socket strip -+- wall-wart - TV -------+
                                |                        |
                                +- wall-wart -+-+        |
                                |             | |        |
                                |          GND| |+3.3V   |(TV lead)
                                |             | |        |
                                |             +-n---+    |
                                |             | |   RxProp----+
                                |             | +---+  |      |
                                |             | |      |      |
                                |             | |      |      |(Com1)
                                |             +-n---+  |      |
                                |               |   TxProp--+ |
                                |               +---+       | |
                                |                           | |
                                |                     (Com2)| |
                                |                    -------+ |
                                |                   /         |
                                +- wall-wart - Laptop---------+
    
    



    <edit>
    BTW:
    With a packetsize (PS) of 512 I saw a throughput of about 627Kbps; with PS set to 1024 I saw about 700Kbps - great work Beau yeah.gif

    Also, I found the minimum waitcnt values were as follows: PS = 512, waitcnt = 520_000; PS = 1024, waitcnt = 735_000.
    </edit>

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,

    Simon
    www.norfolkhelicopterclub.co.uk
    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
    BTW: I type as I'm thinking, so please don't take any offense at my writing style smile.gif

    Post Edited (simonl) : 12/5/2007 12:05:27 PM GMT
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-12-05 16:39
    Simon,

    Glad that you got it working!

    With three different wall-warts, the likely hood of creating a ground loop, shouldn't but might increase... One thing to do would be to check the ground potentials from each supply with a DMM (Digital Multi Meter) without anything connected to see if·there are any noticeable differences.... Ideally, they should all read 0V, but under a typical circumstance, I would expect small voltage variances measuring between the output GND connections.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2007-12-12 06:09
    14.5 Meg Baud Upgrade using 4 I/O Pins....
    This is still work in progress.· Using only 1 COG for the Transmitter, and 1 COG for the Receiver, 14.5 Mega Baud Communication Packets can be achieved.
    With slight modification to the "Transmitter" (using 1 COG) and "Receiver" (using 2 COGs ; 180 deg out of phase) 29 Mega Baud communication packets should
    be achieved through the current implementation of 4 - I/O pins

    The current demo sends pseudo random Packets with a length of 32768 bits in approximately 2.25mS (<-14.5Mega Baud) at a repetition rate of 174 Hz
    effectively providing a constant throughput of 5.7 Mega Baud.· Keep in mind that the 174 Hz is deterministic of the overhead required for the display and
    Packet confirmation.· Also, the demo provides a "real time" visual representation of the Transmitter's I/O state displayed on the·Receiver screen.

    Enjoy!!
    ·

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.

    Post Edited (Beau Schwabe (Parallax)) : 12/12/2007 7:06:59 AM GMT
  • AleAle Posts: 2,363
    edited 2007-12-12 08:06
    Beau,

    The sender looks nice, but is not very realistic. When you have other cogs manipulating output pins, you cannot happily ROL outa contents... you need 5 instructions...

    rol buff,#4
    mov temp1.buff
    and temp1,#PIN0_4_MASK
    and OUTA,#PIN0_4_MASK
    or OUTA,temp1

    or did I miss something ?

    EDIT: I DID miss something, see below.... ***

    Post Edited (Ale) : 12/12/2007 8:21:11 AM GMT
  • BaggersBaggers Posts: 3,019
    edited 2007-12-12 08:10
    Ale, doesn't DIRA control the output's so you can only have it affect 1 pin?
  • AleAle Posts: 2,363
    edited 2007-12-12 08:18
    I thought DIRA was kind of "global" so you could change any out put that is configured as an output from any cog... let me check the manual....

    Nononono, I'm mistaken... the problem is not that DIRA is not unique, it is unique per cog, and does not reflect the other cogs' status. Niether do OUTA, they are all OR'ed together and independent, and they only contain the value written, not all the OR'ed values. Very clever. Understood.

    Beau, do not worry.

    Baggers: Thanks for the rethinking...
Sign In or Register to comment.