Electronics notes/Various wireless notes

From Helpful
Jump to: navigation, search
This is for beginners and very much by a beginner.

It's intended to get an intuitive overview for hobbyist needs. It may get you started, but to be able to do anything remotely clever, follow a proper course or read a good book.

Some basics and reference: Volts, amps, energy, power · Ground · batteries · resistors · changing voltage · transistors · fuses · diodes · varistors · capacitors · inductors · transformers · baluns · amplifier notes · frequency generation · skin effect

And some more applied stuff:

IO: Input and output pins · wired local IO · wired local-ish IO · ·  Various wireless · 802.11 (WiFi) · cell phone

Sensors: General sensor notes, voltage and current sensing · Knobs and dials · Pressure sensing · Temperature sensing · humidity sensing · Light sensing · Movement sensing · Capacitive sensing · Touch screen notes

Actuators: General actuator notes, circuit protection · Motors and servos · Solenoids

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · JY-MCU · DMX · Thermal printer ·


Noise stuff: Stray signals and noise · sound-related noise names · electronic non-coupled noise names · electronic coupled noise · ground loop · strategies to avoid coupled noise · Sampling, reproduction, and transmission distortions


Audio notes: See avnotes

Microcontroller and computer platforms Arduino and AVR notes · ESP series notes · STM32 series notes · · · ·


Less sorted: device voltage and impedance, audio and otherwise · electricity and humans · power supply considerations · Common terms, useful basics, soldering · PLL · pulse modulation · signal reflection · resource metering · SDR · Project boxes · Unsorted stuff

See also Category:Electronics.



Contents

License-Free and ISM bands and such

ISM bands were reserved partly to avoid RF communication in these bands, so that certain industrial, scientific and medical ('ISM') devices could use these frequencies without having to worry about causing interference.


The sub-GHz part of these are associated with some basic remotes, older garage remotes, wireless weather stations, home automation, that sort of low-data-rate use (that often deal with interference just by repeating their message a bunch) though there are newer things, like 802.15.4 (e.g. ZigBee) and LoRa using it for more complex communication.

The largest reason is probably that manufacturers do not need to buy licenses to put out products that use these ranges.

In particular 2.4GHz, where the recognizable names include WiFi and bluetooth.


There are a few other bands that are not strictly ISM but are similar in legal practice.


The best known bands seem to be:

  • 13.56 MHz (center of 13.553 MHz ~ 13.567 MHz)
worldwide
e.g. RFID/NFC
  • 315MHz (a.k.a. 310MHz?)
(mostly US/Canada) (verify)
not ISM(verify)


  • 433Mhz, a.k.a. 434MHz
Usually refers to 433.05–434.79MHz, the center of which is 433.92Mhz
ISM band used in ITU region 1 (Europe, Africa, part of the middle east, former Soviet Union)
there are be local variations of how large this range is (e.g. in the UK(verify))
not usable in other regions
various devices use ~5mW-50mW of transmitted power(verify) with various antennae to reach 100m, 200m, sometimes over 1km of line-of-sight range(verify)
Users: various short-range household remote devices
LPD433 defines 69 channels (25kHz spacing) with at most 10mW


  • There are some license-free bands used largely for walkie talkies
Europe: PMR446 at 446Mhz
US: FMR and GMRS at 462 and 467MHz


  • 868Mhz
refers to an unlicensed band in Europe (not ISM, but usable under similar terms (verify))
The extend varies. You may see references like 868.0-868.6MHz or 863-870MHz or 868-870MHz, 869MHz, 868.35, etc.
Split into sub-bands, each with their own typical sort of use, limitations on transmit power and duty cycle. Some have channels, some don't. (see e.g. [1]), SRD860
Documents seem to contradict each other on detauls, so this probably varies per region and probably has over time as well.
People seem to like 869.4..869.65 MHz sub-range - it's one of the wider ones, allows the strongest transmission (500mW) and a decent duty cycle (up to 10%), if you meet certain conditions
Not usable in the US because of 824–894MHz mobile bands(verify)
One of the RFID ranges (865–868) is in/near this, though since it too is short-range it ought not to cause too many interference problems.
I have seen mention of 860.48–879.51 - what's this?(verify)
Users: various short-range household remote devices (e.g. remote controlled switches, wireless thermometers, some home automation), a few wireless mice, one variant of ZigBee, (check more (verify))


  • 915MHz (center of 902..928 MHz)
the common name for, and center of, the 902-928MHz band
ISM band in ITU region 2(meaning America)
Note this is close to the 935-960 MHz (or is that 872-960 MHz?) mobile band (verify)
not usable in Europe because of that mobile band (verify)
Users: various short-range household remote devices and some computer peripherals, IEEE 802.15.4 (Zigbee), (check more (verify))


  • 2.400–2.500 GHz, also referred to by its center, 2450MHz
Note: Microwave ovens are also right in the middle of this. Little makes it out of them, but if well-placed it may still interfere(verify)
Users: IEEE 802.11 (WiFi), Bluetooth, IEEE 802.15.4 (Zigbee), some short-range household remote devices and some computer peripherals, some cordless phones (verify)



Lesser known:

  • 27.12 MHz (center of 26.957 MHz .. 27.283 MH)
  • 5.8 GHz (center of 5.725 GHz .. 5.875 GHz)
  • 24.125 GHz (center of 24 GHz .. 24.25 GHz)
  • 61.25 GHz (center of 61 GHz .. 61.5 GHz)



See also

order of meters

IrDA

Old IrDA could do dozens of kbit/s, much like serial port of the time.

New variants can do multiple Mbits (fastest variant 1Gbit/s in theory), and are recently seeing some different applications (e.g. fast photo transfer).


Line of sight signalling, so in many uses fell out of style in favour of things like WiFi and Bluetooth.


Range:

  • ~1m max, half that is typically best for speed(verify)
  • For lower power devices it's ~20cm.
  • ((verify)whether high-speed devices are shorter-range)

See also:

Bluetooth

Bluetooth works in 2.4 - 2.4835 GHz, in 79 separate 1Mhz channels

Bluetooth continuously hops channels, to lessen the probaility of consistent interference with other devices and other protocols (in particular 2.4GHz WiFi). Busy areas still have congestion problems, though.


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Versions and speed

Maximum speed:

  • Bluetooth 1.1 and 1.2 versions is 1mbit in theory, ~700Kbit/s in practice
  • Bluetooth 2's EDR can reach maybe 2Mbit in practice,
  • Bluetooth 3 plain is still that ~2MBit
Bluetooth 3 HS can do ~24Mbit -- if and when it can basically hand over to WiFi(verify)
  • Bluetooth 4
had the previous rates, but changed low power details
BLE (max 1Mbit) is a new stack alongside the classic Bluetooth 1-to-3 one -- because it was actually developed separately and merged into bluetooth 4
  • Bluetooth 5
mostly didn't change rates
though increases speed of BLE to 2 Mbit/s when at short range

Range

Range is primarily a function of transmit power:

Class 3: ~1m
Class 2: ~10m
Class 1: ~up to ~100m, and some modern devices could do perhaps 250m in theory

More added over time. Class 3 (1m)came later, as did Class 4 (~0.5m), Class 1.5 (~20m).

Shorter-ranged bluetooth means less collision/congestion in general.


Many devices are class 2, as this is a good balance for things like headsets, headphones, PDAs, smart watches, so more would not be necessary yet probably shorten battery life.

Bluetooth dongles might be class 2, or 1 but note that between any two devices, the highest class (lowest transmit power so shorter range) matters.

Also, even if both are Class 1, that theoretical 100m may be more like 30m through a wall or two.


As such, when you need more than 10m, you will need to pick and set up hardware for the specific case (much like WiFi).

Latency

Latency in general

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Bluetooth has inherent latency, coming from a few different things, like

packet size - larger packets may mean slightly more throughput (because less overhead), but take more time to send so also mean higher latency (which is all generic network theory stuff)
congestion (it's in the same band as all other Bluetooth devices, and some other things
Bluetooth version, as recent versions introduced some newer features


In practice, it is fairly likely that the communication layer can move a packet to another device in perhaps 8ms.

Some of those packets may arrive in maybe 3ms, but that's roughly the best case you can barely even guarantee under lab conditions, and you will not consistently get that when there are other devices in the band.

So you can be happy if you get an fairly-consistent average of ~5 to 10ms.

When frequencies are reasonably congested, you can assume you get perhaps 15ms jitter (variation in latency).



This varies a little by use.

For low-speed data transfers, this is still pretty much blink of an eye scale.

If on the other hand you make music, you may care about audio, and about MIDI.

Latency around audio

Audio

Audio isn't exactly the smallest packets.

But audio has a larger issue, namely that regularity is important, because if some data is later than scheduled, it's an audible gap, i.e. choppiness / stutter.


The basic fix is to schedule it later. By always buffering some amount of milliseconds of audio.

Even reasonable congestion adds on the order of 15ms of jitter (=variation in latency), so you probably want a buffer of at least 25ms, so that what comes out of that buffer will probably never be empty.

...but it'd still fail under heavier congestion.

Both transmitter and receiver can do this, and since neither side knows or controls what the other does, you may get buffers at both sides, which quickly adds up, and few setups will go under 40ms or so.

Also, smartphones may buffer some more, so that they can sleep their CPU more of the time, saving battery.

Add no-brand bluetooth audio transmitters, and the total latency may creep up to 200-300ms. Even 500ms isn't crazy to see.


The codec side of this is a little confusing.

aptX in the broad sense may only aim for 50-150ms, which is barely better than classical bluetooth. Only aptX LL aims for 40-50ms.

And there are some cases without aptX LL that are actually just as low latency(verify).



How much do you need?


Note that when listening to just music, this doesn't matter at all, because what's it going to be late to?


For movie watching, you probably won't notice when audio is 30ms late, that's one or two frames. Your brain may easily adjust up to to 100ms. More than 200ms is going to look wrong to most of us. I've measured my headphones at more than that, and I still only really notice it when thinking about it.

There are some practical ways to deal for this, e.g. your video player or TV delaying the video by a small, configurable amount to make it match up better (some detect the delay they need - see e.g. iOS Wireless Audio Sync and many things like it)


Music production and recording is a more complex matter. Brains are actually quite good at compensating 5-10ms anyway, as you'll get about that much from people playing in a large room anyway just for speed-of-sound reasons.

Yet some music recording and audio engineering tasks stand and fall with latency, and those you will grab your wired headphones. Because no bluetooth wireless audio can be pushed to <5ms reliably.

That said, some other DAW tasks need a little latency compensation anyway, so may be fine. And in DAWs yo can offset recordings. Yet "150ms" and "by ear" in the same sentence is going to make many people unhappy.


Competitive gamers will also care. On principle if nothing else.


(Note that wireless headphones used to be analog RF which had negligible latency - but that was noisier and barely exists anymore)



MIDI

MIDI is a little different.

For one, the packets are tiny, and in theory you could send data send as soon as possible and get under 10ms for most notes.

However, if congestion means that notes may come in maybe 20ms late, that messes up regularity and timing.

The kind that freestyle playing can sort of get away with, but you wouldn't really want in a serious product, so again, it makes sense to (send timestamps with notes and) add a delay on the receiving end to be able to guarantee regularity.

So in practice bluetooth MIDI tends not to aim for the very lowest latency either.

It's also why you probably never want a bluetooth drumkit.


Devices that don't care about low latency have other implementation details, like the ability to use less power when they don't have to pay all the attention to bluetooth. So very few try for 8ms, few for 40ms, and most are more on the 'a few hundred ms is fine'.



Audio

Headphones (and speakers)

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

When looking for wireless headphones, look at the audio profiles.


Headsets made for phonecalls originally often used a profile that allow only phone-quality sound, apparently HFP (hands-free profile) or the older HSP (headset profile).


Headphones meant for music may (and bluetooth speakers and such usually will) support A2DP instead to get music-quality sound (not audiophile guaranteed, but good enough for the bulk of us). (Note that A2DP also supports the lower-quality modes, and the devices may also support HFP and/or HSP for compatibility, so configuration can matter, but you can often assume a setup picks the best it's capable of)

A2DP devices tend to also support remote volume control via AVRCP.


When considering bluetooth sound (e.g. music around the house), keep in mind that many transmitters are class 2 and so do at most 10 meters (...both ends matter, since both are transceivers), and that limited bandwidth may may degrade quality (instead of cutting out. In particular some headsets seem to do this).

There are some Class 1 headphones out there. They (almost per definition) use more power, so tend to have shorter battery life.


If you like your own headphones, you can buy a battery-powered A2DP-capable receiver and plug your own favourite headphones into those. These are usually class 2 devices. Class 1 variants are regularly mains powered (their point apparently being less cable clutter).


Serial module notes

BC417

BlueSMIRF

RFID, NFC, contactless smart cards

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

In RFID (Radio-frequency identification), the "identificaton" points at that this started as little more than "I am tag with this number" (very basic, and not particularly secure).

We've built a lot on top of that since, making it more general communication.


RFID often refers to a few specific designs, most of which are small - and fairly easily hidden, particularly in/on/as small surfaces, relatively hidden devices.


It's used in things like:

  • In supply management ('what shipment is this', etc.)
  • As a high-tech dogtag of expensive items, or items in general (books, clothes, sometimes everything sold in a store)
because they can be fairly small and hidden
(note that there are other, simpler tech for stores, e.g. 8.2MHZ EAS and 58 kHz acoustomagnetic)
  • Access control (often used purely as tokens, i.e. one-factor security)
  • Passports
  • Chipping your pets uses a variant of RFID(verify)



On power

There are:

  • passive tags
which use an external source of power - often the communication itself (the reason for the large coiled antennae?)
can be very small and thin, and therefore almost invisibly embedded in many things.
common, because you don't need to care about power at all
  • active tags
battery-powered (...so limited lifespan and more expensive)
can signal autonomously
can be used over considerably larger distances
can often communicate faster
  • battery assisted passive (BAP)
active tags that take negligible power from their batteries until triggered by communication
cannot signal autonomously

Frequency use

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


Sorted approximately by common use:

  • Low-frequency - 120-150kHz range
for many countries often specifically ~125 or ~134.2 kHz
these are more or less interchangeable
You can fairly easily get readers (and writers) for this.


  • High-frequency - 13.56 MHz (worldwide ISM(verify))
Used in access badges, bank cards, library cards, loyalty cards, etc.
Example: Mifare (which is sometimes known for )


  • Ultra-high
    • 433MHz
    • 868MHz (EU unlicensed) and ~915MHz (US unlicensed) (think ISM)


  • Microwave
2.4Hz and 5GHz - expensive tags


In term of 'what's in your wallet', it's probably mostly ~125 / ~134 kHz, and 13.56 MHz (verify)


Security criticism

RFID/NFC blocking wallet

Notes on cards and protocols

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Proximity card

Early proxcards hold about as little as a magnetic stripe card.


Originally and mainly passive cards (typically at 125kHz, and correlated with ISO 7810 ID-1 sized cards), powered by the reader so must be held close.

Active proxcards have a battery (lifetime generally on the order of a few years), and may be contacted at 2 meters or so, and a few more, useful for things like automated toll collection, gate opening, and such.


T5557
EM4100
Unsorted

NFC

NFC (Near Field Communication) can be thought of as an extesnsion.

It refers to things conforming to to ISO 14443 (proximity, ~10cm max range) or ISO 15693 (vicinity), and RFID usually refers to quite varied systems mostly described by the older ISO 18000.


In practice, the fact that RFID and NFC are used somewhat fuzzily means that people often use

RFID to mean older simpler identitying (and often 125kHz) implementations,
and NFC to mean mean newer, fancier, communicating (and often 13.56MHz) implementations.

The best way to be sure is to figure out the specific tech being used.


NDEF
Android Beam and similar

Contactless smart card

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


Seems to refer to cards with

a read-only CSN/UID
a read-write IC
some basic security
usually in a ISO 7810 sized card (but also in keyfobs, etc.)

...which makes them a little more complex than classic proxcards.


Typically at 13.56 MHz ('RFID HF')


Protocols vary, but MiFare is one of the largest.



See

ISO 14443 - proximity cards at 13.56MHz
Type A and Type B, same protocol but varying modulation, coding, init
ISO 15693 - vicinity cards (~1meter) at 13.56MHz
ISO 18000 - varied systems at different frequencies
below 135kHz
at 13.56MHz
at 2.45GHz
within 860MHz .. 960MHz
at 433MHz

https://en.wikipedia.org/wiki/Contactless_smart_card

Biometric passports
EMV

Contactless payment

The acronym originally stood for its creators, "Europay, Mastercard, and Visa" https://en.wikipedia.org/wiki/EMV


MiFare

https://en.wikipedia.org/wiki/MIFARE


NFC tags
Security

https://en.wikipedia.org/wiki/MIFARE#Security_of_MIFARE_Classic,_MIFARE_DESFire_and_MIFARE_Ultralight

Calypso

https://en.wikipedia.org/wiki/Calypso_(electronic_ticketing_system)


CIPURSE

https://en.wikipedia.org/wiki/CIPURSE


EU identity cards

https://en.wikipedia.org/wiki/National_identity_cards_in_the_European_Economic_Area

See also

order of dozens of meters

Note that some of these can be pushed to hundreds or perhaps a thousand meters -- in specifically designed setups.

WiFi

See Electronics notes/802.11 (WiFi)

Simple/slow short-range wireless on 315MHz, 915 MHz, 433MHz, or 868 MHz

Radio frequency communication used for things like home automation, car remotes, some wireless mice and presenters, RF-triggered flashes in photography, and more.

Many applications need only one-way communication.


Often uses ISM bands. The sub-GHz bands uses are often

  • 315MHz or 915MHz in the US
see e.g. FCC Part 15.231, 15.205; 15.247, 15.249
  • 433MHz or 868MHz in Europe
see e.g. ETSI EN 300 220
  • 433 in Africa (verify)
  • 315MHz or 433MHz in Asia (verify)
  • 315MHz or 426MHz in Japan (verify)
see e.g. ARIB STD-T67
  • 433MHz or 915MHz in Australia (verify)

...because these are license-free bands (given you stick to some basic restrictions - mostly power output (range) and duty cycle, largely to make sure products will play nice enough with each other around).


Many of these bands have multiple frequencies/channels that specific devices may be tuned to a specific sub-ranges/channel, and may use various modulation.

Range

For most devices the primary limits are lowish transmission power, and the (often-simple) antenna.

This is often more or less by design, to avoid causing interference.

Some things stop working at one or two dozen meters, while a few things are designed for 100m or 200m. You may be able to get 1km in ideal conditions.

Modulation

Signal modulation is often either ASK or FSK, or sometimes PSK, which are three fairly basic ways of modulating data - via amplitude, frequency, and phase:

  • ASK, Amplitude shift keying [2], often specifically:
    • OOK (the simplest and probably most common form of ASK)
  • FSK, Frequency shift keying [3], including:
    • BFSK, a.k.a. 2-FSK, is probably its most basic form
    • GFSK applies a Gaussian filter to pulses, to control its (out-of-band) bandwidth, and for more power efficiency, at the cost of some smearing between symbols (verify)
    • MSK is a type of continuous-phase frequency-shift keying, which makes more efficient use of the aether
      • GMSK adds the Gaussian filter details to MSK
  • PSK, Phase-shift keying [4], not used much


When buying devices, the common acronyms are ASK, FSK, GFSK, MSK, and OOK.



See also:


Speed

Speed in sub-GHZ ISM is typically low, in part because of a specific channel's bandwidth (which sometimes helps meet certification requirement). in part to make it more robust around noise, with simpler (and therefore cheaper) hardware.

The simplest devices may use bit lengths of on the order of 1ms, for an effective data rates of a few hundred bits per second.


Slightly fancier designs may be listed as 4800bits/s or 19200bits/s or so, in some cases up to perhaps 256kbps or 500kbps .

...in relatively ideal conditions. A speed like 100kbits/s is already hard to do reliably.

In theory you can do more, but in practice you have to consider distance, noise, interfering senders in the same band and thereby retransmission.


Since there is no exact reference timer, line codes often use things like Manchester coding[7] or something else where bit trains are unambiguous without strict timing.

Line code, protocol

Line code specifies how exactly user data is coded on the channel. This is often designed with the physical medium in mind.

The most basic radios do not apply a line code, just mirror the state of an input pin on the aether (with whatever modulation they do), and receivers mirror that on their output pin again, maybe sending their command a few times in a row, but otherwise leave it up to simple encoder/decoder chips to fix noise issues, collission issues, or other robustness/cleverness.

Fancier radios may act more like serial ports/modems with a small FIFO buffer, and may use a coding that tries to avoid noise and timing issues.


There are many device-specific protocols - often somewhat proprietary, but often easy enough to interpret and imitate if you wish.

A good number of such applications will use a matching pair of ICs (one encoding on the sending side, one decoding on the receiver side), to encode/decode the data to whatever function they have and with specific protocol/function assumptions hardcoded.


You often see protocols use a preamble, so that the receiver can have automatic gain adjustment, without missing the start of basically all packets (since such receivers often end up adjusting to maximum gain when they hear no transmissions).

Other signals

You pretty much have to be able to deal with other senders in the same band.

There are duty cycle limitations on devices (via certification, anything you bought will adhere). This often means yours probably gets through soon enough. Things like remotes (which rarely send) may well send something a few times in with some short interval, just to increase the chance one gets through.


If you want to avoid erronously acting on someone else's data, you'll probably want to make your protocol include protocol-specific and/or product/project-specific values.

In things like home automation there are typically also per-device addresses (which you can often physically set on each device) to make devices specific to a house, or even a room or so.

Some protocol names

Within home automation, protocols / device implementations include (very very roughly from wider to more specific use):

You can often find specific details in some general-purpose DIY home automation projects.


  • Domia lite / Bye Bye Standby (BBSB)
    • there's a simple and an advanced variant of the protocol
  • KlikOn-KlikOff (a.k.a. KlikAan KlikUit (kaku) and other translations)
    • Seems to often use PT2262 (encoder) and PT2272 (decoder) ICs [8]
  • Home Easy [9]
  • Byron
  • W800RF32 (X-10 RF wireless?)
  • Conrad FS20 (868.35 AM (/915?))
    • based on house codes (8 digits?) (meant for isolation from your neighbours) and addresses (256 of them)
    • addresses are subdivided into 225 unique addresses, 15 function group addresses, 15 local master adresses, and 1 global master address -- mostly for the ability of independent and/or grouped addressing of any device
  • Oregon Scientific
    • protocol version 1.0
    • protocol version 2.1
    • protocol version 3.0
  • Ikea Koppla (434 MHz)
  • Skytronic Homelink
  • Harrison (Curtain Motors)
  • Intertechno (434 MHz)
  • Visonic
  • Flamingo
  • ATI Remote Wonder / Medion
  • NEXA
  • Waveman
  • Proove
  • Duwi
  • other devices such as thermostats, wireless doorbells, weather stations, toys, utility
    • Elro AB600 (433MHz) (dimmer?)
    • La Crosse TX3 / TX4 (weather station)



See also (unsorted)





RC aircraft and such

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


On the airplane control-protocol side, we have

PWM
length of pulse sets position - in milliseconds
the oldest, most standard, and often a default
each channel has a wire on the receiving end, which is a bit chunky
CPPM
PPM means position of pulse sets position
the C basically means it's defined to let you send all channels over a single wire (timesliced, 20ms frames)
not sure why they didn't use PWM in such a framing, it might've been less work?(verify)
S.BUS (developed by Futaba)
digital
Spektrum sattelite (verify)
digital


Note that PWM and PPM in this context actually refer using these modulation types in a somewhat more specific standard. This is why elsewhere you'll find them called "RC PWM", "RC PPM"



http://pages.cs.wisc.edu/~bolo/rc/radio_types.html

http://users.belgacom.net/TX2TX/tx2tx/english/tx2txgb1.htm

http://rcarduino.blogspot.com/2012/11/how-to-read-rc-receiver-ppm-stream.html


https://robotics.stackexchange.com/questions/4456/pulse-position-modulation-as-used-in-rc-controls

On range, walls, and antennae

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)



802.15 (including zigbee)

802.15 in general describes wireless personal area network (WPAN), including many things on a localish scale. See http://en.wikipedia.org/wiki/802.15

You're likely looking specifically for 802.15.4, "Low Rate WPAN"


802.15.4 ("Low Rate WPAN")

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


Useful for sensor networks, usually more so than other options (such as Bluetooth), because of things like meshing, and the option to use little power.

The most basic protocol attempts to ensure proper delivery (checksum, ACKs, retransmission), which is a whole bunch of work you don't have to do yourself.


Range is ~100m in theory, some variants more, though in general you shouldn't count on more than two dozen meters - much like WiFi. Range is usually limited by antennae (often the thing you can change most), by ISM regulations on transmit power, and other factors.


Data rate is lowish - a few dozen kbps user-usable speed on 2.4Ghz (verify), ~9kbps on 900MHz (verify)


On names, protocols, (xbee) series, firmware, and other variations

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Some of the basic terms:

  • 802.15.4 (protocol)
    • There are currently two revisions, IEEE 802.15.4-2003 and IEEE 802.15.4-2006
    • mostly specifies the physical communication layers (PHY, MAC), which allows basic point-to-point and broadcast communication. The module being sent to must be in sight (no relaying of messages). Anything more complex than that has to happen by additional protocols provided on top, such as ZigBee, MiWi, WirelessHART.
    • http://en.wikipedia.org/wiki/802.15.4
  • ZigBee (protocol)
    • A protocol specification defined by the ZigBee Alliance
    • There are currently four versions, ZigBee 1.0 (2004), ZigBee 2006, ZigBee 2007, and ZigBee 2007/Pro
    • a mesh network; nodes can relay messages. That is, end devices talk only to routers, routers can relay, and and a network must have one coordinator. All nodes could be set up as routers (though that takes more power)
    • Compared to basic 802.15.4, ZigBee adds that mesh routing, some extra encryption, node association (and can require authentication to do so)
    • http://en.wikipedia.org/wiki/Zigbee
  • XBee is a brand name from Digi International (formerly MaxStream), mainly referring to a line of products with a shared pinout (but not all of which are compatible on-air)


  • XBee Series (mostly seen: 1 and 2) basically refers to products with different chipsets
    • terminology specific to Digi. Mostly seen on 2.4GHz Xbees, and seem more rarely used on other modules.(verify))
    • Firmware is made for a specific chipset. As a result
      • Series 1 (freescale chipset) can run 802.15.4-compliant firmware and Digimesh, and is often sold with a name including 'Series 1' or '802.15.4'
      • Series 2 (ember chipset) can run ZNet 2.5 and ZB (ZigBee implementations) and maybe sold with names including ZNet 2.5, ZB, and S2B.
    • Series 2B seems to be a physical redesign of series 2 (its pro variants) to squeeze out a little more power. Otherwise equivalent to Series 2.
    • Series 2C - (verify)
    • Series 3 seems to refer to XSC (verify) (the reference is not seen much)
    • Series 4 seems to refer to to 900MHz devices. (verify) (the reference is not seen much)
    • Series 5 seems to refer to to 868MHz devices. (verify) (the reference is not seen much)
    • You cannot communicate between series 1 and 2 xbees (but apparently almost entirely because of because of protocol differences. (verify))
  • XBee Pro versus plain XBee
    • most of the difference lies in transmit power and range
    • Not to be confused with Zigbee Pro
  • ZigBee Pro
    • is about ZigBee 'stack profiles': Plain zigbee (ZigBee stack profile 1) is simpler and enough for most home and many commercial uses. ZigBee Pro (ZigBee stack profile 2) adds multi-casting, many-to-one routing and has some more security options. (verify)
    • Both non-pro and pro can do mesh networking, but Pro seems to be a little better at it larger-scale networks (verify)
    • It seems you can mostly mix Pro with non-Pro (unless you use Pro's high security mode) (verify)


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Some of the most confusing details come from the fact that chipset, Xbee series, usable firmware and resulting protocols are all entangled.

Also, even within the same protocol you can use firmware to make nodes take different roles

(note also that Digi XBees are not the only devices that speak 802.15.4 or ZigBee, though if this summary focuses on them)


On protocols:

Protocol-wise, a device can speak speak bare 802.15.4, ZigBee, or something else. For example, XBee also sees use of DigiMesh. These are distinct protocols, and most are incompatible on the air.


  • 'raw' 802.15.4 protocol
    • Talks to (all) neighbouring devices.
    • sleeps most of the time. Does time synchronization so that everything talks in bursts (which saves power, particularly when there is little to communicate)
    • The easier option for point to point (and broadcast, a.k.a. point to multi-point) communication, but it doesn't do all the things ZigBee can, particularly meshing
    • for Xbee: firmware that speaks this is made only for Series 1 (freescale), not for Series 2 (Ember) chipset.
  • Digimesh protocol
    • A meshing protocol, functionally much like ZigBee, but not compatible with ZigBee
    • Originally only available for 900MHz devices.
    • Now also usable by Series 1 XBee, but not with series 2 Xbees (you want ZigBee instead)
    • Allows sleeping routers, saving power.
    • (some extra notes about digimesh and versions of series 1: [12])
  • ZNet protocol - an implementation of Zigbee by Ember
    • Can be considered an interim implementation; you probably want ZB instead
    • XBee: usable by series 2, not by series 1. Series 2 (which use Ember chipsets) seems shipped with Znet 2.5 (perhaps more recently shipped with ZB?)
  • ZB protocol - an implementation of ZigBee, coded to the 2007/Pro version of ZigBee - a better feature set than ZNet
    • Xbee: Usable by series 2, not series 1.
    • (based on Ember ZNet 3?)
  • There was a beta version of a freescale ZigBee stack (i.e. ZigBee for Series 1) but it was discontinued. [13]

See also:


On firmware:

You can load various types of firmware into the modules. This defines both what protocol it speaks. In ZigBee meshing it also defines what role it takes (and note that a ZigBee network must have one coordinator) The rest of the devices can be routers, or endpoints (which can use less power).

For XBees, the series represent different chipsets:

  • Series 1 can run basic 802.15.4 or Digimesh
  • Series 2 can run Znet 2.5 or ZB (implementations of earlier and later spec of ZigBee)


What you can do is restricted by

  • the hardware chipset (when keeping to Digi's XBees, series 1 and series 2 refers to different chipsets)
  • the implementation details of the firmware you can load on specific devices/chipsets (e.g. digimesh was originally available only on 900Mhz modules, now also on series 1 Xbees (2.4GHz))

...which mean you can get meshing on Series 1 - but only by using DigiMesh, so which won't talk to ZigBee meshes.


From the perspective of XBee hardware:

  • XBee Series 1
    • comes with 802.15.4 compliant firmware. Can be configured to interact with different-brand 812.15.4
    • can use DigiMesh
    • cannot use ZigBee(verify)
  • XBee Series 2
    • comes with ZigBee-compliant firmware.
    • cannot use plain 802.15.4 firmware(verify)
    • cannot use DigiMesh(verify)


See also:



802.15.4 specific notes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

PHY-level notes

  • 2.4GHz band, or 915MHz / 868MHz bands (see #ISM_bands_and_such).
    • 2.4GHz is faster and works worldwide, but has shorter range (50mW for up to 1.6 km. best case 7km?). Speed ~250kbps on air, a few dozen kbps of throughput you can use, 16 channels
    • 915MHz (US): slower, more range (best case 24km?). Only in pro variant?(verify), ~40kbps, 10 channels
    • 868MHz (Europe), slower, more range (best case 40km?(verify))though ISM regulation limit transmit power. ~20kbps, 1 channel.


MAC-level notes

  • 802.15.4 defines FFD (Full function device) and RFD (Reduced functionality device). FFD can talk to everything and can be coordinators, RFDs can only talk to coordinators, and are end devices (which, because of this, can be lower power and cheaper).
  • Coordinators remember network details, and handle routing. Needs more memory and RAM. (XBee firmwares choice: coordinator, or router/endpoint)
  • Association with PAN coordinator (basically to avoid overloading the coordinator)
  • Discover devices listening to beacons
  • Addressing can be 16-bit (local - within PAN associated nodes?(verify)), or their full 64-bit address
  • Encryption


ZigBee specific notes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)
  • Node types:
    • ZigBee coordinator - FFD acting as a PAN coordinator in the network
    • ZigBee router - FFD that is not the PAN coordinator, but acts as a local coordinator (routing between devices, supporting associations)
    • ZigBee end device - RFD / FFD that is neither coordinator or router. Talks only to coordinator or router, not to other end devices (Can be lower power since the interesting routing is done elsewhere)
  • Routing:
    • Star
    • Cluster Tree - sort of like spanning-tree, subnet-style routing. Seems deprecated, not part of Pro
    • Mesh - (FFDs) can talk to everything in sight, algorithm figures out paths. Part of ZigBee and ZigBee Pro
      • Many to one routing, source routing


Thread

https://en.wikipedia.org/wiki/Thread_%28network_protocol%29

DigiMesh notes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


On (Not) Talking to other modules

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


Protocol

A protocol will only understand itself.


Channel

You can only talk to the same channel.

  • The 2.4GHz band has 16 channels defined (within 2400-2480MHz. Each ~2MHz wide), numbered 0x0B through 0x1A (Default is 0x0C). A number are reserved, and it seems Xbee Pro uses fewer(verify). [14]
  • The 915 MHz band has 10 channels (0x01 through 0x0A)(verify)
  • The 868 MHz band has 1 channel (0x00) (verify)

In XCTU: Networking → CH

(There is also the concept of channel pages. This basically means the same frequency bands, with different sorts of modulation. Usually fixed in a product, and for the 2450 MHz band there is only one choice. It's likely you don't really need to worry or know about it)


PAN ID

XBees will ignore packets not from the same PAN ID. It is a quick and dirty way to avoid confusion between distinct networks/projects without having to keep track of members, or have an in-protocol .

XBees all default to 0x3332.

In XCTU: Networking → ID


Addressing

Roughly speaking

  • A device has a SL and SH, which are unique and cannot be changed. They are each a 32-bit int, so combine to be a 64-bit hardware identifier (think MAC)
  • You can
    • send only to a known node by unique 64-bit ID (set a DL,DH, which must a known node's SL,SH (respectively) in communication). Useful to locally focus traffic to (only) a specific known node.
    • send to a group (with a particular MY; must match a value set in SL)
      • DigiMesh does not use this (no MY)

DL and DH default to 0, which uses matching by DL=MY. MY us 0 by default, which means that everything listens to everything


In general, for transmitted packets:

  • If DH=0x00000000, DL=0x0000FFFF: Broadcast (received by everything)
  • If DH=0x00000000, DL<0x0000FFFF: Received for modules whose MY matches the DL
  • If DH>0x00000000 or DL>0x0000FFFF: Received for modules whose SH=DH and whose SL=DL

On range and power

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


'Power use notes:

  • Power use is not directly related to transmit power - because of sleeping and such
  • Assume something like 40mA to 50mA for transmits and receives.
  • Pro and longer-range variants may use 200 or 300mA to transmit. Varies with hardware design.
  • Idle communication module will use a small amount of power, varying per design; ~10mA for some, down to something like ~10uA for others.
  • ZigBee sleeps less than bare 802.15.4; Meshing will mean more power use for routers (...than its endpoints)(verify)

See also:



On range:

'Up to' figures are misleading as they count on ideal setups, high gain antennae, clear line of sight (preferably good fresnel zone[15] clearance). They are achievable, but don't expect them in urban or indoor settings.

The factors you can most easily choose or influence:

  • obstructions (...as always) - line of sight and ground clearance will give you more range. Obstructions, reflections and no clearance will give you less.
  • band (~900MHz variants could do 20-30km with good antenna, the basic 2.4GHz ones in the 30m-1500m range), and possibly 100 mW (20 dBm) (verify)
  • transmit power. Vary per design, but the approximate Range / mW correlation for 2.4GHz XBees (Slight difference between Series 1 and Series 2):
    • 1mW (0dBm): ~30m indoor, ~90m outdoor
    • 2mW (3dBm): ~40m indoor, ~120m outdoor
    • 10mW (10dBm) (XBee Pro, International ISM limitation): 90m indoor, 1000m outdoor (verify)
    • 50mW (17dBm) (Series 2 XBee Pro, North American version): ~120m indoor, ~1500m outdoor
    • 63mW (18dBm) (Series 1 XBee Pro, North American version): ~120m indoor, ~1500m outdoor
    • Note that in Europe and other places, ISM compliance means you cannot transmit with more than 10mW (10 dBm)
    • Count on somewhat less than this when using a wire/chip antenna
  • antenna (simple variants have either a chip antenna or a wire antenna; wire often a little better)
    • Chip - perhaps -1.5dBi(verify) Don't suck as much as you may think, but still the simplest, least-range option
    • Wire - perhaps 0dBi to 2dBi(verify). Somewhat better range than chip, though indoor the difference is often less pronounced
    • Antenna connector, usually U.FL or RP-SMA on XBee Pro. Make sure the antenna you buy is for the frequency the module uses.


See also:


X-CTU notes

Serial ports

XCTU is a little finicky with COM ports, in that it doesn't refresh ports while running. Matters when plugging USB-to-serial devices, such as the arduino's.

Remember that XBee radios need a few seconds to start up.

Default baud rate is 9600. You can program an XBee to default to something else.




Unsorted

  • Bee refers to the 20-pin, 20mm pitch attachment
    • ...a socket used by XBee, but also by the GPS Bee, Bluetooth Bee, RFBee, and others (the common feature seems to be devices that do serial communication)
    • XBee Pinout: http://code.google.com/p/xbee-api/wiki/XBeePins
    • You can communicate using just just four pins (ground, 3.3V power, RX and TX), though also using and respecting RTS is a good idea that can avoid some headaches. The rest are optional, convenient for specific applications, seeing activity, specific features/designs, and such.


Basic pragmatic usage notes:

  • Usually have a serial interface (think AT commands), and can be used to pass through IO
  • Xbees are 3.3V devices - power and IO too (IO doesn't seem 5V tolerant). There are adapter boards that do regulation and level shifting. You could do this yourself (possibly cheaper), but they are are convenient.


Boards you can use to interface with XBees (and that are often sold by the DIY-style stores that sell XBees):

250mA regulator, level shifted IO. Seems to be the cheapest (and arguably better than the sparkfun ones). (Not made to plug directly into an Arduino shield-style, but not much work to hook up to one. Will hook directly to a FTDI cable)
regulator (used to be 150mA, now 500mA(verify)), drops RX line via diode, receiving serial should be able to deal with 3.3V TX from module. You can solder in headers to get to all Xbee pins.
  • Some specific arduino derivatives, such as the Seeeduino Stalker, have Xbee sockets (may be wired a little differently, so e.g. programming may be different/harder)
  • (could you use an AVRless arduino's FTDI at 3.3V?)

Regulator max current is relevant as Pros at full power use 200 to (worst case) around 340mA (...but less if you may only use 10mW, perhaps 170 mA?(verify)). If they do so in bursts you can get away with lower specced regulators (perhaps with a capacitor), but if they draw continuously then a 150mA regulator won't cut it.



See also:

TOREAD:


Somewhat applied:


Digi RF device offering


Kilometers or more

Cell phone

Cell phone networks do connections of ~1km, which is why we need a good number of masts for coverage.

See also Cell phone


WiMAX

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

http://en.wikipedia.org/wiki/WiMAX



LPWAN

Low-Power Wide Area Networks (LPWAN) groups things that are low-power and long range, mainly:

See also https://www.sciencedirect.com/science/article/pii/S2405959517302953


LoRa / LoRaWAN

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

LoRa is a physical layer, and proprietary, so it's a somewhat specialized yet useful thing.

LoRaWAN is a network layer on top of physical that allows routing


Band: 433 MHz, 868 MHz / 915 MHz

Speed: ~50kbps

Range: ~5 km in urban settings, ~20km in rural settings


Example uses include tracking animals against poaching, tracking loan-out vehicles, utility meters, and the like


https://en.wikipedia.org/wiki/LoRa


Sigfox

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Uses 868 MHz (Europe) or 902 MHz (US)

Speed: ~100 bits per second

Range: ~10 km in urban settings, ~40km in rural settings

https://en.wikipedia.org/wiki/Sigfox


NB-IoT

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Band: mobile LTE (licensed)

End devices require(verify) a base station, unlike LoRa and Sigfox

Speed: dozens to hundreds of kilobits/s

Range: ~1 km in urban settings, ~10km in rural settings

Latency: seconds


https://en.wikipedia.org/wiki/Narrowband_IoT

VSAT

VSAT refers to one of many specific types of two-way ground stations communicating via satellite.

Many have dishes on the order of 0.6 ~ 1 meter (mobile applications prefer more omnidirectinal antenna types but have similar size)

Band: ~6GHz, ~4 GHz, ~13GHz

Speed: 4 kbit/s up to 16 Mbit/s depending on type


Used in things like

  • Maritime communications.
  • Internet access, in remote places where putting in cable is less feasible
  • Things like SCADA where no other networks are available


https://en.wikipedia.org/wiki/Very-small-aperture_terminal

Not yet sorted

ANT

2.4 ISM band, simple protocol stack.

http://en.wikipedia.org/wiki/ANT_%28network%29


RC

Unsorted

ANT is a proprietary ISM-band system, lower-power than e.g. 802.15.4 (ZigBee),

Retrieved from "https://helpful.knobs-dials.com/index.php?title=Electronics_notes/Various_wireless_notes&oldid=71984#RFID.2C_NFC.2C_contactless_smart_cards"