Searching \ for '?1Mb/s speed serial comms' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=serial
Search entire site for: '?1Mb/s speed serial comms'.

Truncated match.
PICList Thread
'?1Mb/s speed serial comms'
1997\10\14@204639 by Michael Coop (pjm)

flavicon
face
Ideas wanted: PIC-to-PIC comms at speeds greater than 1Mbit/s ?

The data is in long bursts (typ. 2-3 minutes each 5 minutes).

I suspect that a hardware UART is the only way to even start considering
the problem, otherwise there will be no time for anything else in the CPU !

Also - of course, this is a project that demands huge quantities - so the
final product will need to be l-o-w cost !

The good news is that the links will be no more than 500mm long. The bad
news is that they will be in an electrically noisy environment.

All and any suggestions gladly considered.

Thanks
Michael Coop

Please reply to list - and for the really good stuff - please cc to
spam_OUTmcoopTakeThisOuTspampop.jaring.my

--   --   --   --   --   --   --   --   --   --   --   --   --   --   --
 --
I have no idea how it works, I just know how to use it.
--   --   --   --   --   --   --   --   --   --   --   --   --   --   --
 --

1997\10\14@231054 by John Payson

picon face
> Ideas wanted: PIC-to-PIC comms at speeds greater than 1Mbit/s ?
>
> The data is in long bursts (typ. 2-3 minutes each 5 minutes).
>
> I suspect that a hardware UART is the only way to even start considering
> the problem, otherwise there will be no time for anything else in the CPU !
>
> Also - of course, this is a project that demands huge quantities - so the
> final product will need to be l-o-w cost !
>
> The good news is that the links will be no more than 500mm long. The bad
> news is that they will be in an electrically noisy environment.

Hope you don't mind some more questions:

[1] What type of data?  What error rate is acceptable?  Delivery failure
   rate?

[2] Can the transmitter re-obtain any data that the receiver didn't get, or
   is such data "gone" permanently [in which case data must get through
   first time]?

[3] What sort of electrically noisy environment?

1997\10\14@231528 by Jonathan Baker

flavicon
picon face
In article <.....01BCD945.3EF13FE0.mcoopKILLspamspam@spam@pop.jaring.my>, "Michael Coop (pjm)"
<mcoopspamKILLspamPOP.JARING.MY> writes
>Ideas wanted: PIC-to-PIC comms at speeds greater than 1Mbit/s ?
>
>The data is in long bursts (typ. 2-3 minutes each 5 minutes).
>

Why not use A Parallel interface instead of serial (I think that's what
you were getting at).  That will reduce processing time and is on the
whole easier to program.

--
Jonathan Baker

1997\10\14@234610 by Michael Coop (pjm)

flavicon
face
> Ideas wanted: PIC-to-PIC comms at speeds greater than 1Mbit/s ?

Hope you don't mind some more questions:

[1] What type of data?  What error rate is acceptable?  Delivery failure
   rate?

[Michael Coop]  8 bit random content
No errors... (!) - I don't have a spec on the acceptable error rate, but I
think we can get by with pretty high 'losses', as this is a non-critical
'commercial' application.  Bits inverted are more acceptable than bits
lost, and preferably single bits rather than runs of 'n' adjacent bits.

[Michael Coop]  Delivery failure cannot happen, as each pic takes it's cue
from the preceding unit's data, and as such 'pushes' the data stream
through nn linked pics.

[2] Can the transmitter re-obtain any data that the receiver didn't get, or
   is such data "gone" permanently [in which case data must get through
   first time]?

[Michael Coop]  First time is the only time - bad luck.

[3] What sort of electrically noisy environment?

[Michael Coop]  Located alongside electric rail lines (about midway between
the overhead catenary supply and the undertrain motors, air-cond etc)

Thanks for the interest.  The problems from EMI may not be as severe as I
fear - but I just want to get there before the hardware is cast in stone.

Regards
MC

P.S.  If you think you are on to what we are doing, it's too late - the
patent application is already in <g>.

1997\10\14@234615 by Michael Coop (pjm)

flavicon
face
>Ideas wanted: PIC-to-PIC comms at speeds greater than 1Mbit/s ?
>
Why not use A Parallel interface instead of serial (I think that's what
you were getting at).  That will reduce processing time and is on the
whole easier to program.

[Michael Coop]  The parallel option is still in there, but the number of
interconnects is in VERY large numbers, and the serial option reduces the
hardware points of failure, while being eminently easier to shield and
'keep synchronous'.

We are talking about 10-20 thousand PICs interconnected here - end-to-end.

I would rather maintain 20K 2-wire links than 160K 2-wire links (with
individual shield).

Although I agree that on the short run lengths, it may be feasible to
fabricate some PCB-to-PCB link with embedded shielding and groundplane
pads.

1997\10\15@002026 by Bob Lunn

flavicon
face
Bob Lunn
10/15/97 02:20 PM


> [1] What error rate is acceptable?
>
>    I think we can get by with pretty high 'losses',
>    as this is a non-critical 'commercial' application.

         I'm curious that you can accept a high data
         loss, but require a high data rate...

>    If you think you are on to what we are doing, it's
>    too late - the patent application is already in <g>.

         Ahh, then you don't know much about
         patenting!  :)

___Bob

1997\10\15@003126 by Steve Baldwin

flavicon
face
> Ideas wanted: PIC-to-PIC comms at speeds greater than 1Mbit/s ?
>
> The data is in long bursts (typ. 2-3 minutes each 5 minutes).

Have I read this wrong ?

1Mbit/s for 2-3minutes ? = 22 megabytes of data ?
Where's a PIC going to get it from ?

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: .....stevebKILLspamspam.....kcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1997\10\15@015959 by Dmitry Kiryashov

flavicon
face
Hello Michael .

> Ideas wanted: PIC-to-PIC comms at speeds greater than 1Mbit/s ?
> The data is in long bursts (typ. 2-3 minutes each 5 minutes).
> I suspect that a hardware UART is the only way to even start considering
> the problem, otherwise there will be no time for anything else in the CPU !
> Also - of course, this is a project that demands huge quantities - so the
> final product will need to be l-o-w cost !
> The good news is that the links will be no more than 500mm long. The bad
> news is that they will be in an electrically noisy environment.

There are some technique to increase of serial data transfer rate .
Every period of carrier frequency "phisically" has two level:
the '1' level and the '0' level . Every level has also two possible
duration: t1 and t2 . Due to that appear possibility to send
2 "logical" bit at one "phisical" period of carrier .

For example:
"00" combination send as '0'(t1) '1'(t1)
"01" combination send as '0'(t1) '1'(t2)
"10" combination send as '0'(t2) '1'(t1)
"11" combination send as '0'(t2) '1'(t2)

I think there are another possibilities to increase transfer rate.
For example discuss more time interval not only 2 . But i not
practically
discover it .

The main disadvantage of this method is absent harware
transiver/receiver
build in PIC . So it may be implemented only in software .

WBR Dmitry .

1997\10\15@021935 by Michael Coop (pjm)

flavicon
face
1Mbit/s for 2-3minutes ? = 22 megabytes of data ?
Where's a PIC going to get it from ?

The data at the head of the stream will be fed from a 'different' system... !

1997\10\15@023641 by Andrew Warren
face
flavicon
face
Steve Baldwin <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

> > Ideas wanted: PIC-to-PIC comms at speeds greater than 1Mbit/s ?
> >
> > The data is in long bursts (typ. 2-3 minutes each 5 minutes).
>
> Have I read this wrong ?
>
> 1Mbit/s for 2-3minutes ? = 22 megabytes of data ?
> Where's a PIC going to get it from ?

Steve:

It's not all coming from one PIC; presumably, each passenger's PIC
(I'm assuming that this project involves networking train passengers
together) simply FORWARDS 21.999 megabytes while contributing only
about 1K of its own information to the data stream.

One-megabit-per-second data rates shouldn't be too difficult
(although personally, I'd feel a LOT more comfortable using something
faster than a PIC), and the bit-error rates can probably be kept
fairly low, BUT...

A halfway decent binary-symmetric channel will have a bit-error rate
of somewhere between 1 in a million and 1 in ten million.

If you send a 1000-byte packet through such a channel, it's likely
to be received with no errors.  However, forcing that packet (along
with 20,000 others) to be transmitted 20,000 times in a round-robin
sort of scheme practically GUARANTEES that the message will be
horribly corrupted.

One possible solution to this problem would be to tie each passenger
in a car (or on a whole train) to a central hub, then to do the
round-robin thing only between trains.  On the one hand, adding hubs
would increase the hardware costs and system complexity; on the other
hand, the system might have a chance of working.

I expect that Michael has already thought about the error-propogation
problems that the round-robin scheme presents.  Since _I_ can't
think of a way (absent concentrators, hubs, and really good
error-correction coding) to make it work reliably, I can only assume
that:

   a) he knows something I don't, or
   b) I've completely misunderstood his description of the
      networking scheme.

Maybe he can give us a few more details.

-Andy

=== Andrew Warren - fastfwdspamspam_OUTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\10\15@025056 by Bob Lunn

flavicon
face
Bob Lunn
10/15/97 04:51 PM


> A halfway decent binary-symmetric channel will have a bit-error rate
> of somewhere between 1 in a million and 1 in ten million.
>
> If you send a 1000-byte packet through such a channel, it's likely
> to be received with no errors.  However, forcing that packet (along
> with 20,000 others) to be transmitted 20,000 times in a round-robin
> sort of scheme practically GUARANTEES that the message will be
> horribly corrupted.

    Error Correcting Code.  Regenerate at each node.  Use something
    MUCH faster than a PIC (yay Scenix).

___Bob

1997\10\15@060441 by Michael Coop (pjm)

flavicon
face
> I expect that Michael has already thought about the error-propogation
> problems that the round-robin scheme presents.  Since _I_ can't
> think of a way (absent concentrators, hubs, and really good
> error-correction coding) to make it work reliably, I can only assume
> that:
>
> Maybe he can give us a few more details.
>

I will discuss the project in more detail - quietly... email will work.

Your guess at the design model is quite a long way off the mark, and the
PICs merely have to take the data, look at what they want from it, delay by
a known period then send it out to the next PIC.

The reason for the use of low-cost devices across the board is the need for
some 3-million pieces... these aint going to be PC/104 cards !

1997\10\15@090406 by Andy Kunz

flavicon
face
>>    If you think you are on to what we are doing, it's
>>    too late - the patent application is already in <g>.
>
>          Ahh, then you don't know much about
>          patenting!  :)

Especially if the Senate approves the new Patent treaty.  TELL YOUR SENATOR
(US Citizens only) to VOTE NO!

Andy


==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\10\15@115408 by Pierce Nichols

flavicon
face
On Wed, 15 Oct 1997, Michael Coop (pjm) wrote:

> I will discuss the project in more detail - quietly... email will work.
>

       I'd like to hear about it, if you don't mind. I'm curious what you
need 3 million+ PICs for...

> Your guess at the design model is quite a long way off the mark, and the
> PICs merely have to take the data, look at what they want from it, delay by
> a known period then send it out to the next PIC.

       Yes, but I think the point still stands -- each time you
re-transmit the data, you have a certain chance of there being an error,
and that chance builds up really quickly, so it becomes a serious problem
at the scales you are looking at.

       Pierce Nichols

"I have a work order for the immediate demolition of your reality tunnel."

       -Bob, RAW Construction Corp.

===========================================================================
Geek Code v2.1: d?H+sg+a-w++v+c++UHS+P+L+E+N+K!WM--!V-po+Y+t+5+j+R+G!tvb+++
D+B---e+u*hf+r+*n-y+

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...