TI-H: Radio link stuff
[Prev][Next][Index][Thread]
TI-H: Radio link stuff
From: Aaron Peterson <happy_cobbler@bigfoot.com>
> What is your project website?
Currently no formal written documentation exists. I have a
few mental notes and some hardware possabilities. Before I
spent very much time (of which I have precious little free)
on it, I figured I'd better see what the market looked like.
> There are so many combinations for network configuration... I list a few
> here:
>
> It would be cool if the network hardware supported cables and radio.
I assume you mean some kind of hub configuration, where you
could plug several calculators into one hub, and also give
calculators their own radio link.
This is possable, probably it would be implimented as an I2C
hub that would accept packets for broadcast, and receive
broadcast packets and deliver them on the network segment.
This would require drivers on the calculator, but they would
be the same as the driver used in a 'hubbless' setup, one with
a tranceiver for each calc.
> Hopefully 1 radiopac w/ network would create an active network
> for multiple calculators.
The radio module would basicly just act as a gateway, linking
a physical I2C bus to other physical segments. A physical
segment could have 1 or more calcs connected to it.
It would also have the capability to handle a driverless
calculator, by adjusting switches on the radio module.
> 1 server calc, multiple recieve only calcs
This would be a peer-to-peer network, each calc would have an
I2C address (possably dynamicly assigned). All calcs would
be able to broadcast and receive.
> I like the idea of the use of a commercial radio. What models are you
> considering? Please make sure that it would be reusable in other projects.
> (connected with some sort of cable or socket)
Currently I am looking at the modules available from Radiometrix,
they are used in a wide variety of commercial telemetry applications,
have good range, and come in several capabilities, all the way up to
a $100 packet radio network module (which would be perfect for this,
even includes collision avoidance logic, but is a bit pricy for
most people).
One step down from the packet network module is one that basicly
transfers bits back and forth (can acutally be connected almost
directly to an RS232 port on a computer and used as a wireless
RS232). This would put all the traffic handling into the micro,
requiring a whole hell of a lot more code space and development
time, but it would save a few bucks in hardware. Not really
worth the trouble if you ask me, but possably of more use to
the experimenter that does not use microcontrollers.
> The ability to use the radio like a plain old link would be great for
> transfering drivers. A possibility would be:
<snip>
> Obviously it would be more complicated than this... what happens if more
> than 1 calculator doesn't have drivers?
> Opperators would have to pull thier calcs off the net... (no biggie...) But
> then what's the point?!, everybody has link cables, whynot just get close to
> send the drivers and then go away again?
Thats what I'm thinking. It would be possable to set up
a method of sending drivers via the network, but it adds
complexity, and is not essential. In the intrested of
actually producing a usable product, I would keep the
capability list down. IMO allowing for hubs is starting
to push it, but with an appropriate network setup (using
I2C), its not that difficult, and can actually use some
already written code.
Bryan Fields wrote:
>another thing to consider would be to use a simple antenna (i.e. a 1/4
>wave) and higher power. if this is on 443.92 it would be simple to
>raise the power up to 1-3 watts with a simple pa stage. i take it this
>would be a fm signal which would allow you to use a non linear amp,
>making it more efficient.
The reliable range on the modules is 30m in-building and 120m outdoors,
this seems more than sufficient for most applications. In large buildings
however, I can see the need for longer range.
>what freq. is this link on?
433Mhz or 418Mhz, but this is dependant on the TX/RX modules used
>what chips are you using for the transmitter and receiver?
Planning on Radiometrix modules, hopefully the RPC-433-A,
but possibly the BiM-433-F or TX2&RX2.
>what power level will this put out?
Broadcast power is currently in the 10mW range.
Probably an amplifier could be added as a separate module.
>btw, i am not a digital guy, cant stand the 1's & 0's, so please keep
>that in mind if i stated something that is wrong in this case.
Weird the way some people prefer analog and some digital...
From: <Sassamo16@aol.com>
> i was thinking it could be set up like ethernet using csma/cd
> (carrier sense multiple access with collision detection). I was also thinking
> that you could use multiple frequencies to reduce collisions.
The RPC modules already include collision avoidance (via a
carrier detection and 5ms broadcast preamble, I believe).
> price?-not too much, i'd build it myself of course, but i doubt i'd go more
> than $50
Not going to happen. I expect $150 will be absolute minimum
I'm willing to do it for. The hardware could be re-invented
for less, but I'm not willing to invest the time in hardware
design/debugging and software development.
> drivers?-the less the better, we're limited on speed
Agreed, however, drivers will make the communications
faster and aid in hardware development, since I wouldn't
have to deal with TI's funky protocol. The driver would
transmit a block of about 20 bytes via I2C, then the RF
module would transmit it to the network. To do TI protocol
the micro would have to cache data from the calculator,
transmit, wait for an ack from the receiving RF module,
then continue to send data. Certainly doable, and will
probably be included as an option, but not as nice.
> driverless?-good idea, maybe certain programs could include thier own
> drivers, more specific, to function more efficiently
Preferably programs would interface to a packetized communications
stack in the shell, which would then talk to a specific hardware
device.
> suggestions?-try to get as much done as possible on the link to reduce the
> load on the calc processor;
Conversely, the more the link has to do, the more it is going to
cost and the less likely it is to ever be finished. Also, by
keeping it generic (but with an intelligent interface) it is
more easily reused in other applications.
> while we're already working with radio signals,
> include a headphone jack so we can tune in to our favorite stations; (this
> one might require some advanced programmers willing to put in a lot of time
> and effort)
Won't happen, bring a walkman if you want music.
> make a flash TINOS to replace the TIOS with most functions built
> in; any more ideas?-I'll keep thinking.
Now that would be cool, but hacking the ROM and recalculating the
checksum would probably be a hell of a lot of trouble.
From: Markus Räty <markus.raty@usa.net>
> > Ability to have the link operate in a 'network' mode,
> > where several calc's can communicate together.
>
> #2 (Maybe also a possibility to switch 2 calcs into a 'private' mode, so
> they wouldn't need need any id stuuf slowing the link down and wouldn't also
> be bothered by the other calcs linking on the network.)
'private' mode would basically be a compatibility mode, but would still
require each calc have addresses (set with DIP switches on the link).
Otherwise only two calcs could operate in this mode in any given
environment.
> > An option to switch between driverless TI-protocol mode
> > and a software driver mode (for backwards compatibility
> > mostly, to allow existing custom link protocols to work).
>
> #2 (The TI-protocol would propably be nearly vital to my suggestion at the
> end and also a compatibility mode would be needed for asm games.)
Compatibility mode and TI mode could be the same thing,
depending on how slow compatibility mode ends up being.
Otherwise, TI mode would end up being a byte-wise transfer.
> > Long range (over 30-75 meters in-building).
>
> #1 (Could this be done so, that you'd have a knob which you turn to
> determine the range?
Yes, by attenuating the signal to the antenna.
> I myself think I'd easily use 30+ meters of range, but
> as it might get interference on the way from other radio sources and stuff,
> it would be great to be able to adjust the range with the knob, so you could
> try to cut out as much interference as possible, or boost the range, if
> there was no interference or the other link could not be contacted.)
With an amplifier module the range could probably be extended
to somewhere in the range of 300M indoors, maybe 800-1000 outdoors.
FCC ain't gonna be too happy though..
> Could I have a module that plugs into my computer so it could send files
Since the link programs look like a calculator you could attach the output
of a $4 serial cable to the radio module in compatibility mode and transmit
it to the calculator. This would require two radio links, and would be
slower than just connecting the cable.
"Having major planets disappear is always a bad sign." -- Jim Blinn
From: Nick <zaphod@coe.neu.edu>
> someone else do the protocol... but any digital protocol plugged into the
> mic jack of a commercial radio, say one of those nifty Motorola FRS jobs,
> would give you a range of around 1/2 to 1 mile... and plus, each system
> would be totally independent of frequency, so just say "channel sixteen" to
> your friend and you have your own private link w/o interference... also,
> most FRS radios have "quiet codes" to not activate the audio out unless the
> code is received.
>
> FRS (family radio service) radios are decent, FM, license-free, and cost
> anywhere from $50 to $150. Cheap enough for my sorry ass, especially when
> compared to the work of designing FM circuitry myself.
Very cool, and a definite possibility, this eliminates any FCC issues,
and only requires the radio, and a microcontroller. I'll look into
this, the private channels and voice capability are a huge benefit
for something not that much more expensive (and that has a warrantee)
> It's gonna be slow, though. It's an analog-to-digital system, being put
> through the voice filters in the FRS radio, so I'd guess that anything over
> 9600bps would not be possible. Some simple error correction would be
> necessary, probably in a program on the TI.
It will likely run slower than that anyway. This isn't really suited
to large data transfers anyway. Its better for ASCII text (chatting,
test 'assistance' :) etc), and game synchronization messages, etc.
> what i wonder, is if you can get the TI to do the protocol work -- you can
> send & receive raw bits on the link port, so just make IT do all the work.
Yes, this would be compatible with the existing software drivers that
use I2C or something similar. Programs might need a little bit of
tweaking, but if they are already designed for network usage it should
be pretty easy.
> 'course, this system wouldn't have TI protocol compatibility -- since the TI
> protocol is a mite funky, you'd need lots of extra circuitry to convert back
> and forth, plus you might run into bandwidth problems. So, it's a question
> of programming vs. hardware, and programming's free.
Converting would be fairly easy, a microcontroller reading TI protocol
and encapsulating it in byte-sized packets would probably work.
> With minimal hardware, (minus the radio, of course) this thing would cost
> all of five bucks to make (no microprocessor required, just a couple of
> diodes and an op-amp),
Since the micro only costs about $2 there isn't any reason not
to use it, particularly since it can give you the TI protocol
compatibility, and do lots of other handy stuff with the data.
DK
Follow-Ups:
References: