EmbeddedBlue Transceiver AppMod
dx9s
Posts: 7
Anybody with experience (expertise) in this RF device. Also anybody with any RF experience can relay information too!
I am curious if it is possible (the PDF manual is not clear) to setup a communication bus -- and as this device appears to be emulating a serial line (connecting two devices), I really don't know.
I am interesting in using this RF (or any RF device) with Parallax's Stamps in where each device has the potiential to communicate with any other device (in range) -or- setup a polling method (a host) that switches rapidly from device to device. Each RF endpoint will be two-way (transceiver) and needs to be polled once every few seconds. [noparse][[/noparse]scaling] The possibility of having up to 20 or more devices (perhaps even 40) is desired.
I am researching RF two-way multi-point (with a broadcast-like topology) communication as a componet to a larger project and I need options. the datarate doesn't need to be high (2400 bps would be adequate, 9600 bps would be much better, any higher is a bonus). I need to be able to at LEAST perform a broadcast (shared-bus), when one person transmits, everybody in range will receive the message.
Any traditional mechanism for wireless serial interface (auto-transmission for guarenteed error-free reception) is not needed, as the protcol (to be designed) will be responsible for packet delivery assurance (if needed) and checksum validation. devices are not equal and must be polled from a master device (or an array of EmbeddedBlue spread out to provide coverage over the topolgy).
2400/8/40 = max 7.5 half-duplex bytes per device per second (assuming 40 endpoints not including retransmissions and trashed packets)
9600/8/40 = max 30 half-duplex bytes per device (assuming 40 endpoints).
Bluetooth would be a decent "wireless" transport but only if the intra-device communication supports a "shared-bus" mode (and no error-correction/retransmission, left to high level app to manage that)
The closes analogy (that comes to mind) to a wired "network" would be 10base2 (thinnet) where colisions can occur and data can be corrupted -- but everybody has equal chance at being heard. in an old 10base2 (non switched) network, technically everybody hears everybody else, it is the NIC drivers that block packets from being passed up to the operating systems. 802.11b for my purposes is too pricey, not "overly" secure and way to common. Bluetooth also suffers from the same issues but is less likely to have RF issues/conflicts.
The only other hardware (that probably has a better chance of working) would be "433.92 MHz Transceiver (SIP/solid/raw)" and price wise, is a trade off. However the distance mentioned appears to be 1/2 (so more master polling devices would be required for a given area). However that device appears to have a low datarate -- and I still haven't design a protocol/packet framework.
Thanks for your advise and I look forward to hearing from some RF gurus out there!
--Doug
P.S.> If I am not making any sense -- My appolgies
I am curious if it is possible (the PDF manual is not clear) to setup a communication bus -- and as this device appears to be emulating a serial line (connecting two devices), I really don't know.
I am interesting in using this RF (or any RF device) with Parallax's Stamps in where each device has the potiential to communicate with any other device (in range) -or- setup a polling method (a host) that switches rapidly from device to device. Each RF endpoint will be two-way (transceiver) and needs to be polled once every few seconds. [noparse][[/noparse]scaling] The possibility of having up to 20 or more devices (perhaps even 40) is desired.
I am researching RF two-way multi-point (with a broadcast-like topology) communication as a componet to a larger project and I need options. the datarate doesn't need to be high (2400 bps would be adequate, 9600 bps would be much better, any higher is a bonus). I need to be able to at LEAST perform a broadcast (shared-bus), when one person transmits, everybody in range will receive the message.
Any traditional mechanism for wireless serial interface (auto-transmission for guarenteed error-free reception) is not needed, as the protcol (to be designed) will be responsible for packet delivery assurance (if needed) and checksum validation. devices are not equal and must be polled from a master device (or an array of EmbeddedBlue spread out to provide coverage over the topolgy).
2400/8/40 = max 7.5 half-duplex bytes per device per second (assuming 40 endpoints not including retransmissions and trashed packets)
9600/8/40 = max 30 half-duplex bytes per device (assuming 40 endpoints).
Bluetooth would be a decent "wireless" transport but only if the intra-device communication supports a "shared-bus" mode (and no error-correction/retransmission, left to high level app to manage that)
The closes analogy (that comes to mind) to a wired "network" would be 10base2 (thinnet) where colisions can occur and data can be corrupted -- but everybody has equal chance at being heard. in an old 10base2 (non switched) network, technically everybody hears everybody else, it is the NIC drivers that block packets from being passed up to the operating systems. 802.11b for my purposes is too pricey, not "overly" secure and way to common. Bluetooth also suffers from the same issues but is less likely to have RF issues/conflicts.
The only other hardware (that probably has a better chance of working) would be "433.92 MHz Transceiver (SIP/solid/raw)" and price wise, is a trade off. However the distance mentioned appears to be 1/2 (so more master polling devices would be required for a given area). However that device appears to have a low datarate -- and I still haven't design a protocol/packet framework.
Thanks for your advise and I look forward to hearing from some RF gurus out there!
--Doug
P.S.> If I am not making any sense -- My appolgies
Comments
·· Using the EB500 modules, you can wirelessly connect two BASIC Stamps together.· You are using the serial line, and therefore each Stamp is essentially communicating with the other over a wireless serial bus.· Note that you can only connect to one module at a time.· The modules connect via MAC Address, and you can only connect to one of these before having to disconnect and re-connect to the next.· So if you were hoping to have multiple communications channels open at once, it won't work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
I sent a short/quick request to RFDIGITAL if they had any RF devices (like the 433Mhz discussed eariler) that functions as a "shared-bus". If nobody has one of these devices, then perhaps it is something that Parallax should look into developing. It is important to have a "shared-bus" in many applications, in my case need a wireless shared bus (non-assured delivery is acceptable/understandable, like UDP versus TCP). I could do what I need to do (technically) using 802.11b in ad-hoc via a broadcast 802 packet. But I don't see any 802.11b "native" hardware available for BS2. Perhaps there is something in-the-works that provides the discussed RF features.
--Doug
Not familiar with trying to use Bluetooth in a single master/multiple slave arrangement. But, I have worked with RF data radios to do exactly what you describe.
What you are creating is actually the equivalent to a half-duplex bus, like a standard RS-485 network.
You'll have one radio be the master and each remote device will be a slave. The master broadcasts to everybody else, but only the slave whose address was contained in the broadcast message responds. This reduces the need for radios to be set up with hard ID codes. Any slave radio can be used in any slave location. The intelligence of whether to respond is in the receiving stamp.
The other neat thing about this implementation is not needing very rigorous error checking and CRC or LRC which are always an implementation pain, IMHO!
Cheers,
Tom Sisk
Not totally familar with RS-485, but I do have some (little) experience with J1850 VPW (an automotive "shared-bus" that has bit-for-bit collision detection and avoidance -- It is an interesting method using 4 encoding methods to encode two states (1 or 0) -- it is a TTL setup and uses edge detection (timing between the edges and the direction, low-high / high-low, to encode a bit, zero always wins and win you are encoding a one, you much check for somebody else possibly encoding a zero -- really smart and fairly fast).
What RF hardware have you used (assuming BS2 family)?
I had already planned to broadcast/poll with simple CRC (8-bit XOR w/ bitshift or something). If simple checksum is bad, discard. For slaves, do nothing more, for the master unit, can re-broadcast and re-request the last packet.
As for the BlueTooth hardware (mentioned), it only provides point-to-point (it appears to be 802-MAC-like, but doesn't support broadcasting).
I don't have any need for hardware level addresses (as that will be handled in the high level protocol/software) unless there is a broadcast function within the hardware (802.11b / "Wireless" ethernet).
It sound like RS-485 (I need to research, I understand RS-232 & RS-422 ; all point-to-pint) is the exact analogy that need to - found http://www.rs485.com/rs485spec.html
But use an RF (wireless) equivelent to RS-485 is it!
--Doug
·· In theory you could use the EB500 if you're having the master contact each slave unit one at a time.· That still constitutes one connection, each being based on the destination MAC address.· None of the slaves would be making a connection, just receiving one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
BTIDs are used to uniquely identify bluetooth devices (Blue Tooth I.D., the bluetooth version of a MAC)- these unique IDs allow a device to be 'discovered' by others, but once communication is established, connection schemes for a piconet are established- generally one of four:
BD_ADDR
AM_ADDR
PM_ADDR
AR_ADDR
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
RClarke@Parallax.com
I suspect that I am NOT the only one that would like to have an inexpensive (not that ~$100 is low cost) wireless (RF) network that provides decent datarates (9600bps or greater) for BS2 projects. If I am, then I am feeling alone right now ( ). This would open up a hold mode of distributed embedded devices that can inner communicate without wires. Obvious for some, security would be an issue. For others, higher reliability.
Digital Spread Spetrum (DSS) / Frequency Hoping (FHSS) allows for better co-existance and fault tolerance. The ESSID in 802.11b (and a/g) is nearly analogous to the "privacy" codes used in FRS, doesn't keep others from NOT listening, but helps block out others not using the same ESSID ('% iwconfig wlan0 essid any' will receive any packets [noparse][[/noparse]encrypted or not] for a given channel under linux). Bluethooth's piconet probably has similar (probably just as weak as WEP for 802.11b) security measures that are a good first line of defense.
I look forward to hearing from RFDIGITAL and Tom as to alternative RF hardware.
Perhaps the solution is to come up with an updated Bluetooth adapter for BS2 that supports improved "networking" (using piconets) functions/features. The hardware design (in mind, and documenting on paper) really needs to have a wireless equivelent to RS-485.
--Doug
Post Edited (dx9s) : 9/21/2005 3:50:57 PM GMT
Will get you more information on the equipment/programs. What range is needed? Most of my work is 1500 feet and beyond, so $100 per point is almost unheardof! Getting the radios to the $200 each level was a big breakthrough.
BTW, get a copy of Jan Axelson's book "serial port complete". Covers all things RS232 /422/485, including specific Stamp examples.
Have to travel a few days for the "day job", but will get back to you ASAP.
Tom Sisk
Can do a LOT with basic UDP (in fact, you can do anything, some VPN products support "tunneling" an entire network over UDP packets). I know IP well and very basic UDP and VERY basic TCP "handling" could be emplemented. I don't know if there is any wired Ethernet Modules (in use) for BS2, but I thought I saw it. The only need would be to include an additional wireless control interface along with the standard Ethernet ( / IP).
Also, there is no need to actually use IP! Could just use a custom Ethernet packet type that is ether "unused" or allocated for experiemental 802 packet types. Understand that the IEEE 802 standard has been implemented in many ways (Ethernet, Tokenring, even Arcnet). 802 is a good solid standard (well documented) and works well / there are also plenty of 802(.2/.3/.5/.11) implenmentations. And 802 packets can be bridges (from Tokenring to Ethernet, to wireless Ethernet.
Just a thought!
--Doug
Range, the more the better, 150 would be okay, 300 would be better. 1000 feet would be great!
The only two devices (from the Parallax website) that I looked at was
http://www.parallax.com/detail.asp?product_id=27997 (~$100, ~150feet) (some RF device @ ~433Mhz)
-and-
http://www.parallax.com/detail.asp?product_id=30068 (~$100, ~300feet) [noparse][[/noparse]the Bluetooth device)
Thanks Tom!
--Doug
P.S.> I have come to the conclusion that the existing bluetooth hardware is probably not effective enough for my needs.
I have started a related topic
http://forums.parallax.com/forums/default.aspx?f=15&m=88785
that covers the RF module (part no. 27997).
Thanks for your input -- and I hope I was posting this thread (and the other) in the correct location!
--Doug
Post Edited (dx9s) : 9/21/2005 11:02:39 PM GMT