This topic has probably been covered before, but I missed it.

I'm looking for a place to buy soldering tools in North Seattle.  I
don't really need anything fancy, but I am looking for a pair of flush
side cutters and possibly an anti-static mat.  I've tried Radio Shack,
but they didn't have anything suitable.  Neither did the local
hardware store.  Everywhere has soldering irons, but I haven't found
the other tools I need.

I know Fry's has exactly what I want, but its quite a ways away, and
I'd like to find something closer.  I haven't tried Home Depot, but I
doubt they'll have what I need.

Any suggestions?  I live near Northgate.

Thanks,

Charles Cook

There is Vetco in Bellevue (they recently moved again?), Westlake electronic
supply in, well, Westlake.  There is Radar Electric in Bothell Canyon Park
which has a walk up counter.  I am sure there are some others.  I dunno if
there is one near you, but Graybar Electric (a big distributor for all sorts
of stuff: house wiring through networking) - in fact any wire distributor
probably has the tools you are looking for.

www.jameco.com and www.mpja.com has tools.  If you order on-line and specify
USPS priority mail you will get your stuff in two days.

-----Original Message-----
From: cbc2287

This topic has probably been covered before, but I missed it.

I'm looking for a place to buy soldering tools in North Seattle.  I
don't really need anything fancy, but I am looking for a pair of flush
side cutters and possibly an anti-static mat.  I've tried Radio Shack,
but they didn't have anything suitable.  Neither did the local
hardware store.  Everywhere has soldering irons, but I haven't found
the other tools I need.

I know Fry's has exactly what I want, but its quite a ways away, and
I'd like to find something closer.  I haven't tried Home Depot, but I
doubt they'll have what I need.

Any suggestions?  I live near Northgate.

Thanks,

Charles Cook

Charles,

You could go to http://outpost.com/   This is Fry's online store and you
could order what you want there.

John Edwards
botbuilder@...
http://webpages.charter.net/grizzlyrobotics/

----- Original Message -----
From: "cbc2287" <cbc2287@...>
To: <SeattleRobotics@yahoogroups.com>
Sent: Saturday, May 01, 2004 12:43 AM
Subject: [SeattleRobotics] Looking for soldering tools in North Seattle


> This topic has probably been covered before, but I missed it.
>
> I'm looking for a place to buy soldering tools in North Seattle.  I
> don't really need anything fancy, but I am looking for a pair of flush
> side cutters and possibly an anti-static mat.  I've tried Radio Shack,
> but they didn't have anything suitable.  Neither did the local
> hardware store.  Everywhere has soldering irons, but I haven't found
> the other tools I need.
>
> I know Fry's has exactly what I want, but its quite a ways away, and
> I'd like to find something closer.  I haven't tried Home Depot, but I
> doubt they'll have what I need.
>
> Any suggestions?  I live near Northgate.
>
> Thanks,
>
> Charles Cook

fry electronics.
    they have all of this and more

   ----- Original Message -----
   From: cbc2287
   To: SeattleRobotics@yahoogroups.com
   Sent: Friday, April 30, 2004 9:43 PM
   Subject: [SeattleRobotics] Looking for soldering tools in North Seattle


   This topic has probably been covered before, but I missed it.

   I'm looking for a place to buy soldering tools in North Seattle.  I
   don't really need anything fancy, but I am looking for a pair of flush
   side cutters and possibly an anti-static mat.  I've tried Radio Shack,
   but they didn't have anything suitable.  Neither did the local
   hardware store.  Everywhere has soldering irons, but I haven't found
   the other tools I need.

   I know Fry's has exactly what I want, but its quite a ways away, and
   I'd like to find something closer.  I haven't tried Home Depot, but I
   doubt they'll have what I need.

   Any suggestions?  I live near Northgate.

   Thanks,

   Charles Cook




   Visit the SRS Website at http://www.seattlerobotics.org
   Yahoo! Groups Links







[Non-text portions of this message have been removed]

Thanks Larry (and others),

The ordering online idea had occured to me, but I'm looking for
immediate gratification.  Well, actually, I'm hoping to do some
assembly on Sunday, and wouldn't get mail order in time for that.

-Charles

--- In SeattleRobotics@yahoogroups.com, "Larry Barello" <yahoo@b...>
wrote:
> There is Vetco in Bellevue (they recently moved again?), Westlake
electronic
> supply in, well, Westlake.  There is Radar Electric in Bothell
Canyon Park
> which has a walk up counter.  I am sure there are some others.  I
dunno if
> there is one near you, but Graybar Electric (a big distributor for
all sorts
> of stuff: house wiring through networking) - in fact any wire
distributor
> probably has the tools you are looking for.
>
> www.jameco.com and www.mpja.com has tools.  If you order on-line and
specify
> USPS priority mail you will get your stuff in two days.
>
> -----Original Message-----
> From: cbc2287
>
> This topic has probably been covered before, but I missed it.
>
> I'm looking for a place to buy soldering tools in North Seattle.  I
> don't really need anything fancy, but I am looking for a pair of
flush
> side cutters and possibly an anti-static mat.  I've tried Radio
Shack,
> but they didn't have anything suitable.  Neither did the local
> hardware store.  Everywhere has soldering irons, but I haven't found
> the other tools I need.
>
> I know Fry's has exactly what I want, but its quite a ways away, and
> I'd like to find something closer.  I haven't tried Home Depot, but
I
> doubt they'll have what I need.
>
> Any suggestions?  I live near Northgate.
>
> Thanks,
>
> Charles Cook

I may be mistaken, but aren't these the same, only cheaper and more
versatile?

http://www.qprox.com

-S


[Non-text portions of this message have been removed]

Vetco and Fry's are likely the only place open on Saturday.

-----Original Message-----
From: cbc2287

Thanks Larry (and others),

The ordering online idea had occured to me, but I'm looking for
immediate gratification.  Well, actually, I'm hoping to do some
assembly on Sunday, and wouldn't get mail order in time for that.

I posted your question to the ThereminVision Discussion
group.

http://groups.yahoo.com/group/thereminvision/

Bob Leonard



samthemagical@... wrote:
I may be mistaken, but aren't these the same, only cheaper and more
versatile?

http://www.qprox.com

-S


[Non-text portions of this message have been removed]



Visit the SRS Website at http://www.seattlerobotics.org
Yahoo! Groups Links






---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs

[Non-text portions of this message have been removed]

Hi,

I snagged a pair of Innomedia radio modems off e-bay a while back and
have been using them to provide a data link to my "rover":

	 http://www.bdmicro.com/rover/

To make a long story short, this modem link does not appear to
transmit a zero (null) byte.  I've verified this by explicitly
transmitting 0's from one side to the other, but nothing arrives on
the other end.

They seem to work perfectly other than that.  Doug Leppard's Encoder
article got me going which provided all the right commands and
information to establish a link:

   http://www.seattlerobotics.org/encoder/200011/modem.htm

Now I'm stuck on why null bytes are not transmitted through the link.
Some setting I missed, perhaps?

For the longer part of the story - so far I have only been using a
purely ASCII interface from the controller to the robot.  Just
recently though, I've been looking to incorporate a bootloader into
the MAVRIC-II board which is the main controller of the rover.  The
bootloader emulates a popular Atmel programming protocol so the
software on the other end just thinks its talking to an STK500.  This
will allow me to program the controller remotely over the radio link.
However, the communication fails due to the drop-out of the null bytes
from the data stream.  If I directly wire the link, the bootloader
programming works great.

Any help would be appreciated!

Thanks!
-Brian
--
Brian Dean
http://www.bdmicro.com/

>
>Now I'm stuck on why null bytes are not transmitted through the link.
>Some setting I missed, perhaps?

Many/most radio links perform badly with asymmetrical data.
Normally, you have to manchester encode decode, or go through some other
mechanism to insure that the average of the data, over a timespan determined by
the low frequency response of the link, is zero.

On Sun, May 02, 2004 at 07:13:08PM -0500, David VanHorn wrote:

> Many/most radio links perform badly with asymmetrical data.
> Normally, you have to manchester encode decode, or go through some
> other mechanism to insure that the average of the data, over a
> timespan determined by the low frequency response of the link, is
> zero.

Very true, but I think these modems take care of all that internally.
I think these are supposed to be a "cable replacement" solution.

-Brian

At 08:27 PM 5/2/2004 -0400, Brian Dean wrote:

>On Sun, May 02, 2004 at 07:13:08PM -0500, David VanHorn wrote:
>
>> Many/most radio links perform badly with asymmetrical data.
>> Normally, you have to manchester encode decode, or go through some
>> other mechanism to insure that the average of the data, over a
>> timespan determined by the low frequency response of the link, is
>> zero.
>
>Very true, but I think these modems take care of all that internally.
>I think these are supposed to be a "cable replacement" solution.

I can't think why they would lock out nulls then.
Not very handy, since the workaround is rather ugly (send in hex ascii)

if you have the posablity of XORing the data then XOR it by &H55 before sending
it.

decode at the other end with XOR &H55 also

this is only valid IF you can get to the data befor it is send.
(cheap easy manchester like code)

   ----- Original Message -----
   From: Brian Dean
   To: SeattleRobotics@yahoogroups.com
   Sent: Sunday, May 02, 2004 5:27 PM
   Subject: Re: [SeattleRobotics] Innomedia Radio Modem question


   On Sun, May 02, 2004 at 07:13:08PM -0500, David VanHorn wrote:

   > Many/most radio links perform badly with asymmetrical data.
   > Normally, you have to manchester encode decode, or go through some
   > other mechanism to insure that the average of the data, over a
   > timespan determined by the low frequency response of the link, is
   > zero.

   Very true, but I think these modems take care of all that internally.
   I think these are supposed to be a "cable replacement" solution.

   -Brian


   Visit the SRS Website at http://www.seattlerobotics.org
   Yahoo! Groups Links







[Non-text portions of this message have been removed]

At 06:33 PM 5/2/2004 -0700, tbrenke@... wrote:

>if you have the posablity of XORing the data then XOR it by &H55 before sending
it.
>
>decode at the other end with XOR &H55 also

And the Xor of 0x55 and 0x55 is?

It just moves the problem.

If you are sure that you can not send 0 the best solutions I can think of
are either sending two bytes for each data byte or compressing the data so 8
contiguous 0 bit's don't occur.

In a two byte scheme, you could use the extra bits for one bit checksums,
put the data in the low nibble and it's compliment in the high nibble.  That
would halve your data rate but you would know when you got a bad nibble and
have a good idea of which bit(s) are bad.  A more balanced  but more CPU
intensive way would be to follow each bit by it's compliment.

On the other hand, if data rate is a bigger issue and you have cpu cycles on
the transmitting and receiving end you could compress your data in a way
that does not generate 8 contiguous bits of 0, like with a contrived Huffman
Encoding for example.  A lost or damaged bit will throw off the decode
though.  Packetize the data so that you can resync when you get a RCV error.

Scott Williamson







----- Original Message -----
From: "Scott Williamson" <SOLIDCorp@...>
To: <williamsons@...>
Sent: Sunday, May 02, 2004 8:46 PM
Subject: Re: [SeattleRobotics] Innomedia Radio Modem question


At 06:33 PM 5/2/2004 -0700, tbrenke@... wrote:

>if you have the posablity of XORing the data then XOR it by &H55 before
sending it.
>
>decode at the other end with XOR &H55 also

And the Xor of 0x55 and 0x55 is?

It just moves the problem.



Visit the SRS Website at http://www.seattlerobotics.org
Yahoo! Groups Links

At 09:16 PM 5/2/2004 -0500, SOLID Corp. wrote:

>If you are sure that you can not send 0 the best solutions I can think of
>are either sending two bytes for each data byte or compressing the data so 8
>contiguous 0 bit's don't occur.
>
>In a two byte scheme, you could use the extra bits for one bit checksums,
>put the data in the low nibble and it's compliment in the high nibble.  That
>would halve your data rate but you would know when you got a bad nibble and
>have a good idea of which bit(s) are bad.  A more balanced  but more CPU
>intensive way would be to follow each bit by it's compliment.

Very inefficient.  FEC would be a better bet, and I think it only needs 3 bits
per nybble IIRC.


Check the docs on the link, something's amiss.

Would base-64 (uuencode) work for you?

There are a number of archaic modem protocols from the bad old days
of non-transparent connections. For example, you can poke around in
the Kermit documentation. http://www.columbia.edu/kermit/faq.html

Cheers,
   Chuck

David VanHorn wrote:
>
> At 09:16 PM 5/2/2004 -0500, SOLID Corp. wrote:
>
> >If you are sure that you can not send 0 the best solutions I can think of
> >are either sending two bytes for each data byte or compressing the data so 8
> >contiguous 0 bit's don't occur.

On Sun, May 02, 2004 at 09:21:59PM -0500, David VanHorn wrote:

> Check the docs on the link, something's amiss.

I agree.  It just doesn't make sense that a 0 won't make it through.
It's got to be something else.  I'll keep digging.

-Brian

On Sun, May 02, 2004 at 09:21:59PM -0500, David VanHorn wrote:

> Check the docs on the link, something's amiss.

Well, I think I've ruled out the radio link.  I am able to reproduce
this with a direct wired link.

In my previous test where I thought I ruled out everything but the
radio modem, I was testing directly from PC -> robot with a cable and
was getting success.  But when going through the wireless link, I was
not.  I snooped on the remote side and noted that no 'null-bytes' were
coming though.  I even set up a test to explicitly send 'nulls'
though, but did not see any arrive, while every other byte value comes
through OK.

But also in my normal setup, I have a separate controller that
precedes the radio modem so all data must go through it first.  That
controller has a "pass through" serial port so that I can plug in a PC
and get a link to the robot - the controller reads from one port and
passes it straight through to the wireless link.

This is useful because when I don't have a PC for control, I use a
Playstation 2 gamepad connected to the controller - the controller
reads the gamepad and sends commands to the robot.

So the controller can accept either serial data from a PC and pass it
on to the robot, or it can read control commands from the connected
gamepad and send commands to the robot independent of a connected PC.

Well ... seems as though its the "controller in the middle" that is
not passing the 0 bytes for some reason.  I.e., when I disconnect the
radio modem and patch in from the "controller in the middle" to the
robot with a hard-wired link, I still get the problem of no 0-bytes
being transmitted, even though the radio modem is not involved at this
point.  Thus, I've finally narrowed the problem down - but not yet
solved it.

Hmmm ... I haven't run into this before.  I need to figure this out.
*scratches head*

Sorry for the mis-diagnosis ... I think the modem link is working just
fine.

-Brian

On Sun, May 02, 2004 at 11:18:14PM -0400, Brian Dean wrote:

> Well, I think I've ruled out the radio link.  I am able to reproduce
> this with a direct wired link.

Problem solved.  The moral to this story is to never use a value of 0
as the return value from the function to get serial data to mean that
there were no characters available.  Doh!

-Brian

At 11:18 PM 5/2/2004 -0400, Brian Dean wrote:

>On Sun, May 02, 2004 at 09:21:59PM -0500, David VanHorn wrote:
>
>> Check the docs on the link, something's amiss.
>
>Well, I think I've ruled out the radio link.  I am able to reproduce
>this with a direct wired link.

Erg.

Sounds like NSBasic.  They can't send a null, because they use null terminated
strings instead of counted strings.. But wait, it gets better.  Since they know
people need nulls, they translate FFs to nulls..

At 12:00 AM 5/3/2004 -0400, Brian Dean wrote:

>On Sun, May 02, 2004 at 11:18:14PM -0400, Brian Dean wrote:
>
>> Well, I think I've ruled out the radio link.  I am able to reproduce
>> this with a direct wired link.
>
>Problem solved.  The moral to this story is to never use a value of 0
>as the return value from the function to get serial data to mean that
>there were no characters available.  Doh!

Hmm.. That would make sense I guess.

On Sun, May 02, 2004 at 11:22:33PM -0500, David VanHorn wrote:

>
> At 12:00 AM 5/3/2004 -0400, Brian Dean wrote:
>
> >Problem solved.  The moral to this story is to never use a value of 0
> >as the return value from the function to get serial data to mean that
> >there were no characters available.  Doh!
>
> Hmm.. That would make sense I guess.

And the second moral is when you think you've ruled out everything
else except for the one thing you think is causing the problem because
it's the first time you've used it in this application (the radio
modem for me in this case), double check the obvious even if you've
used it a hundred times before without problems (ring_buffer code in
my case here).  Actually, the code was fine - it was my usage of it
that caused the bug.

	 while ((ch = ringbuf_get(&rbuf)) != 0) {
	    ...
	 }

Instead of:

	 while (rbuf.bufcnt != 0) {
	   ch = ringbuf_get(&rbuf);
	   ...
	 }

The good news is that I can now totally reprogram the 'bot using the
radio link - devoid of any connections other than the radio link, I
just drove it over to the other side of the room, issued the command
to cause a reset in order to enter the bootloader, used my AVR
programming software 'AVRDUDE' running on my Unix workstation and
connected to my "pass-thru" controller which is connected to the other
side of the radio link to reprogram the controller.  I then generated
another reset at which time it started running the new code.  Nice!

Now I don't have to lift that monster up on the bench each time I want
to change the programming :-)

-Brian

Ouch! I feel your pain...

On the lighter side............

Zappe's rule #1: Never underestimate the ability of
anyone to do something stupid, even yourself. NOTE:
this was a hard learned lesson.

Zappe's rule #2: Always start troubleshooting from the
beginning. Never let anyone do it for you, and never
take their word that something has been checked and is
okay.

Corollary to rule #2: The chances that the failure is
located in a module you assume to be good are directly
proportional to the amount of faith you have that the
module is not the point of failure.

Zappe's rule #3: Nothing will fail as spectacularly as
when you try to show someone how good it works. (this
is my most famous and most reliable testing method)

Zappe's rule #4: The liklihood that a simple mistake
on your part will be discovered are directly
proportional to the number of people you ask for help,
and amount of help you ask for. (hey, consitency
counts for something)

Zappe's coding rule #1: Syntactical errors are karmic
justice. (Its the only explanation that I have)

Corollary to Zappe's coding rule #1: Zappe has not
been a karmically good boy!

Zappe's coding rule #2: Encryption is easy, just try
to implement a serial protocol from the basics of 1's
and 0's. Decryption takes a manual. A manual I didn't
write.

Zappe's coding rule #3: If anything can go wrong, it
will be a counter increment on the wrong side of a
curly brace in a 4 level nested loop.

Zappe's coding rule #4: There is nothing wrong with
tons of inline code.... that a contractor can't fix.

They say that 100 lines of working code per day is a
productive rate for programming, but they were talking
about the people who wrote the IDE, not me.

Its really nice to see people helping others figure
out the problems they are having. Even nicer to see
people sharing their learning.

If any of that makes you think... it might help to
note that my next project is a time machine :-)

Also note that Noah was an amateur, the Titanic was
built by professionals. This comforts me... it doesn't
make my code any better, but it comforts me.


--- Brian Dean <bsd@...> wrote:
> On Sun, May 02, 2004 at 11:22:33PM -0500, David
> VanHorn wrote:
>
> >
> > At 12:00 AM 5/3/2004 -0400, Brian Dean wrote:
> >
> > >Problem solved.  The moral to this story is to
> never use a value of 0
> > >as the return value from the function to get
> serial data to mean that
> > >there were no characters available.  Doh!
> >
> > Hmm.. That would make sense I guess.
>
> And the second moral is when you think you've ruled
> out everything
> else except for the one thing you think is causing
> the problem because
> it's the first time you've used it in this
> application (the radio
> modem for me in this case), double check the obvious
> even if you've
> used it a hundred times before without problems
> (ring_buffer code in
> my case here).  Actually, the code was fine - it was
> my usage of it
> that caused the bug.
>
>  while ((ch = ringbuf_get(&rbuf)) != 0) {
> 	   ...
>  }
>
> Instead of:
>
>  while (rbuf.bufcnt != 0) {
> 	  ch = ringbuf_get(&rbuf);
> 	  ...
>  }
>
> The good news is that I can now totally reprogram
> the 'bot using the
> radio link - devoid of any connections other than
> the radio link, I
> just drove it over to the other side of the room,
> issued the command
> to cause a reset in order to enter the bootloader,
> used my AVR
> programming software 'AVRDUDE' running on my Unix
> workstation and
> connected to my "pass-thru" controller which is
> connected to the other
> side of the radio link to reprogram the controller.
> I then generated
> another reset at which time it started running the
> new code.  Nice!
>
> Now I don't have to lift that monster up on the
> bench each time I want
> to change the programming :-)
>
> -Brian
>
>
> Visit the SRS Website at
> http://www.seattlerobotics.org
> Yahoo! Groups Links
>
>
>      SeattleRobotics-unsubscribe@yahoogroups.com
>
>
>





__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover

the problem with most of these is that they have a max "no change" time.
IE sending a 0  (8 bits low) is longer then the time allotted for a non
transition.

I hit that wall once already.
the XOR &h55 cured that.

(XOR 85 in dec form)

&H55 or &HAA,  both work the same.



----- Original Message -----
   From: David VanHorn
   To: SeattleRobotics@yahoogroups.com ; SeattleRobotics@yahoogroups.com
   Sent: Sunday, May 02, 2004 5:34 PM
   Subject: Re: [SeattleRobotics] Innomedia Radio Modem question


   At 08:27 PM 5/2/2004 -0400, Brian Dean wrote:

   >On Sun, May 02, 2004 at 07:13:08PM -0500, David VanHorn wrote:
   >
   >> Many/most radio links perform badly with asymmetrical data.
   >> Normally, you have to manchester encode decode, or go through some
   >> other mechanism to insure that the average of the data, over a
   >> timespan determined by the low frequency response of the link, is
   >> zero.
   >
   >Very true, but I think these modems take care of all that internally.
   >I think these are supposed to be a "cable replacement" solution.

   I can't think why they would lock out nulls then.
   Not very handy, since the workaround is rather ugly (send in hex ascii)



   Visit the SRS Website at http://www.seattlerobotics.org
   Yahoo! Groups Links







[Non-text portions of this message have been removed]

LOL

   ----- Original Message -----
   From: Brian Dean
   To: SeattleRobotics@yahoogroups.com
   Sent: Sunday, May 02, 2004 9:00 PM
   Subject: Re: [SeattleRobotics] Innomedia Radio Modem question


   On Sun, May 02, 2004 at 11:18:14PM -0400, Brian Dean wrote:

   > Well, I think I've ruled out the radio link.  I am able to reproduce
   > this with a direct wired link.

   Problem solved.  The moral to this story is to never use a value of 0
   as the return value from the function to get serial data to mean that
   there were no characters available.  Doh!

   -Brian



[Non-text portions of this message have been removed]

Beautifully spoken sir. I commend you your abilities as a word smith and
your even finer abilities to speak the truth.

LMAO

On Mon, 2004-05-03 at 02:18, Mr S wrote:

> Ouch! I feel your pain...
>
> On the lighter side............
>
> Zappe's rule #1: Never underestimate the ability of
> anyone to do something stupid, even yourself. NOTE:
> this was a hard learned lesson.
>
> Zappe's rule #2: Always start troubleshooting from the
> beginning. Never let anyone do it for you, and never
> take their word that something has been checked and is
> okay.
>
> Corollary to rule #2: The chances that the failure is
> located in a module you assume to be good are directly
> proportional to the amount of faith you have that the
> module is not the point of failure.
>
> Zappe's rule #3: Nothing will fail as spectacularly as
> when you try to show someone how good it works. (this
> is my most famous and most reliable testing method)
>
> Zappe's rule #4: The liklihood that a simple mistake
> on your part will be discovered are directly
> proportional to the number of people you ask for help,
> and amount of help you ask for. (hey, consitency
> counts for something)
>
> Zappe's coding rule #1: Syntactical errors are karmic
> justice. (Its the only explanation that I have)
>
> Corollary to Zappe's coding rule #1: Zappe has not
> been a karmically good boy!
>
> Zappe's coding rule #2: Encryption is easy, just try
> to implement a serial protocol from the basics of 1's
> and 0's. Decryption takes a manual. A manual I didn't
> write.
>
> Zappe's coding rule #3: If anything can go wrong, it
> will be a counter increment on the wrong side of a
> curly brace in a 4 level nested loop.
>
> Zappe's coding rule #4: There is nothing wrong with
> tons of inline code.... that a contractor can't fix.
>
> They say that 100 lines of working code per day is a
> productive rate for programming, but they were talking
> about the people who wrote the IDE, not me.
>
> Its really nice to see people helping others figure
> out the problems they are having. Even nicer to see
> people sharing their learning.
>
> If any of that makes you think... it might help to
> note that my next project is a time machine :-)
>
> Also note that Noah was an amateur, the Titanic was
> built by professionals. This comforts me... it doesn't
> make my code any better, but it comforts me.
>
>
> --- Brian Dean <bsd@...> wrote:
> > On Sun, May 02, 2004 at 11:22:33PM -0500, David
> > VanHorn wrote:
> >
>

Lee S. Johnson
ljohnson@...
Atlantic Communications, Inc.
(757)713-2102


[Non-text portions of this message have been removed]

Congratulations on solving a tough problem.

It's still an interesting topic...

Re. Very inefficient.  FEC would be a better bet, and I think it only needs
3 bits per nybble IIRC.

Yea, I know.  14 instead of 16 bits per byte and you get ECC to boot but you
gain the added complexity of  the ECC, having to handle a bitstream instead
of a bytestream, and you may still not be sure that you won't get 8
consecutive 0 bits.  I'd rather successfully transmit data than rely on
inferring by the ECC that some piece of data did or did not come in.  If you
are going to convert to a bitstream then you may as well compress with a
contrived Huffman encoding which can easily avoid 8 consecutive 0 bits.  It
can be implemented with a lookup table on the TX end.  If the data tends to
have many byte values that are frequent and others that are infrequent
Huffman can do pretty good compression.

I suggested the complimentary nibbles as a byte aligned, VERY cheap, poor
mans Manchester. ; )

A one bit checksum for every 7 bits would prevent 8 contiguous 0 bits from
being send and would be very bit and CPU frugal, it just gets off byte
boundaries.

Scott Williamson


----- Original Message -----
From: "Scott Williamson" <SOLIDCorp@...>
To: <williamsons@...>
Sent: Sunday, May 02, 2004 9:31 PM
Subject: Re: [SeattleRobotics] Innomedia Radio Modem question


At 09:16 PM 5/2/2004 -0500, SOLID Corp. wrote:

>If you are sure that you can not send 0 the best solutions I can think of
>are either sending two bytes for each data byte or compressing the data so
8
>contiguous 0 bit's don't occur.
>
>In a two byte scheme, you could use the extra bits for one bit checksums,
>put the data in the low nibble and it's compliment in the high nibble.
That
>would halve your data rate but you would know when you got a bad nibble and
>have a good idea of which bit(s) are bad.  A more balanced  but more CPU
>intensive way would be to follow each bit by it's compliment.

Very inefficient.  FEC would be a better bet, and I think it only needs 3
bits per nybble IIRC.


Check the docs on the link, something's amiss.



Visit the SRS Website at http://www.seattlerobotics.org
Yahoo! Groups Links

There could be some setting option that instructs the modem to interpet
a null byte as a command to produce a break code. A radio break would be
to send nothing.

Just a thought...


Brian Dean wrote:

>Hi,
>
>I snagged a pair of Innomedia radio modems off e-bay a while back and
>have been using them to provide a data link to my "rover":
>
> http://www.bdmicro.com/rover/
>
>To make a long story short, this modem link does not appear to
>transmit a zero (null) byte.  I've verified this by explicitly
>transmitting 0's from one side to the other, but nothing arrives on
>the other end.
>
>They seem to work perfectly other than that.  Doug Leppard's Encoder
>article got me going which provided all the right commands and
>information to establish a link:
>
>  http://www.seattlerobotics.org/encoder/200011/modem.htm
>
>Now I'm stuck on why null bytes are not transmitted through the link.
>Some setting I missed, perhaps?
>
>For the longer part of the story - so far I have only been using a
>purely ASCII interface from the controller to the robot.  Just
>recently though, I've been looking to incorporate a bootloader into
>the MAVRIC-II board which is the main controller of the rover.  The
>bootloader emulates a popular Atmel programming protocol so the
>software on the other end just thinks its talking to an STK500.  This
>will allow me to program the controller remotely over the radio link.
>However, the communication fails due to the drop-out of the null bytes
>from the data stream.  If I directly wire the link, the bootloader
>programming works great.
>
>Any help would be appreciated!
>
>Thanks!
>-Brian
>
>

At 07:33 AM 5/3/2004 -0500, SOLID Corp. wrote:

>Congratulations on solving a tough problem.
>
>It's still an interesting topic...
>
>Re. Very inefficient.  FEC would be a better bet, and I think it only needs
>3 bits per nybble IIRC.
>
>Yea, I know.  14 instead of 16 bits per byte and you get ECC to boot but you
>gain the added complexity of  the ECC, having to handle a bitstream instead
>of a bytestream, and you may still not be sure that you won't get 8
>consecutive 0 bits.  I'd rather successfully transmit data than rely on
>inferring by the ECC that some piece of data did or did not come in.  If you
>are going to convert to a bitstream then you may as well compress with a
>contrived Huffman encoding which can easily avoid 8 consecutive 0 bits.  It
>can be implemented with a lookup table on the TX end.  If the data tends to
>have many byte values that are frequent and others that are infrequent
>Huffman can do pretty good compression.
>
>I suggested the complimentary nibbles as a byte aligned, VERY cheap, poor
>mans Manchester. ; )
>
>A one bit checksum for every 7 bits would prevent 8 contiguous 0 bits from
>being send and would be very bit and CPU frugal, it just gets off byte
>boundaries.

Agreed. I was just looking to get the most bang for the buck.

As to complexity, the AVR is a pretty capable machine, it wouldn't be starved
for cycles.
I do think that making the low level work properly first is very good technique,
but I always assume a link is errored, even if it's a 3' cable.