Electronics notes/Various wireless notes

From Helpful
Revision as of 14:41, 15 October 2024 by Helpful (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

⚠ This is for beginners and very much by a beginner / hobbyist

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 · batteries · resistors · transistors · fuses · diodes · capacitors · inductors and transformers · ground

Slightly less basic: amplifier notes · varistors · changing voltage · baluns · frequency generation · Transmission lines · 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

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 and video notes: See avnotes


Platform specific

Arduino and AVR notes · (Ethernet)
Microcontroller and computer platforms ··· ESP series notes · STM32 series notes


Less sorted: Ground · device voltage and impedance (+ audio-specific) · electricity and humans · Common terms, useful basics, soldering · landline phones · pulse modulation · PLL · Multimeter notes · signal reflection · Project boxes · resource metering · Radio and SDR · vacuum tubes · Unsorted stuff · 'E-fuse'

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

See also Category:Electronics.



License-Free and ISM bands and such

The sub-GHz part of the license-free bands are associated with some basic remote controls, 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.


A large part of this is what might classically be called ISM bands, 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.

There are further bands that are not ISM in that definition, but legally work out much the same.

note that the more that you get into extra little bits of spectra, the more that those are likely to change. This is one reason products tend not to use them, but see e.g. the messiness around wireless microphones.


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


  • wireless microphones are more interesting, as the bands they use varies more with location
they will certainly try to use license-free ones, but there are products that you basically just can't use anymore.


  • 868Mhz
refers to an unlicensed band in Europe
not ISM, but usable under similar terms (verify)
The extent varies. You may see references like 868.0-868.6MHz or 863-870MHz or 868-870MHz, etc.(verify)
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



Contact, or maybe a meter

RFID, NFC, contactless smart cards

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The origins of RFID (Radio-frequency identification) were about that "identificaton", starting as little more "I am tag with this number" - no real protocol, no security.

'RFID tags' tends to refer to the very small passive tags, 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 simpler and cheaper tech for anti-theft in 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


We've built a lot on top of that since, making it more general communication. RFID often refers to the simpler side (and then often some specific classic designs), NFC (near-field communication') refers to newer, fancier implementation of RFID-like communication




On power

There are:

  • passive tags
which use an external source of power - often the communication itself (part of the reason for the large coiled antennae?)
not having their own power source, these can be very small and thin, and therefore almost invisibly embedded in many things.
common, because not having to care about power at all is very convenient, and also relatively cheap
generally very short range
  • 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)
will stay idle until triggered by communication
and draw negligible power from their batteries while idle
longer range/faster, but longer life than active(verify)
cannot signal autonomously

Frequency use

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Sorted approximately by common use:

  • Low-frequency - 120kHz .. 150kHz range (sometimes even more broadly mentioned as 100kHz .. 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 terms of cards in your wallet, it's probably mostly ~125 / ~134 kHz, and 13.56 MHz (verify)


Security criticism

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Security or privacy was never a design goal of the typical uses of RFID, so using it in security contexts is an issue.

In particular, always keep in mind that communication is unencrypted, and communication with most tags does not discern source.

In other words, you can always snoop on them, you can always talk to them, you can always duplicate what they say.


In some uses (e.g. supply management) this is fine -

you care more about simple and cheap,
care not to have authentication bother reading out items,
you can security-by-obscurity a good enough way if you do need a basic level of that,
and it's not intended to be robust against well informed abuse.



Communication breakdown; RFID/NFC blocking wallet

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


RFID and NFC break down when

  • its antenna is close to another RFID
e.g. two cards of another card of the same frequency is too close to anther card
which is why you get instructions like "present card separately"
  • its antenna close to any large-ish conductor, in fact
tin foil works well enough already


Product-wise, RFID blocking wallets tends to employ scare tactics, partly because there are some cheaper fixes out there than them.

And some fairly practical ones - look at https://www.youtube.com/watch?v=_X6DVQH0Js0


Notes on cards and protocols

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Proximity card

Range-wise 'proximity cards' are contrasted with vicinity cards. Orders of magnitude,

Vicinity roughly means 'should work at 1m'
proximity is 'may work up to 50cm', but usually <10cm meaning 'basically touching'.


Early proximity cards (proxcards) may hold just a few dozen buts (about as little as a magnetic stripe card), some designs maybe a kilobyte.

Depending on purpose, you may opt for read-only ones or read-write ones.


They were originally passive cards, and often still are. 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.


Typically around 125kHz.


Many are ISO 7810 ID-1 sized cards, but they can come in any shape.


There are dozens of subtle variations, varied on-the-air modulations, some standards that settle implementation and and size and protocol and various cards that speak multiple things, so it's not easy to summarize well


T55xx

T5557

T5557 is a Atmel read-write IC at 125kHz with 330 bits of EEPROM.


Has a 330-bit EEPROM, organized as ten 33-bit blocks. You write a block at a time.

Block 0 is reserved for operation modes
Block 7 may contain a password

The first bit is a lock bit. Once set, the IC refuses to alter that block.


Compatible

Extended


https://media.digikey.com/pdf/Data%20Sheets/Atmel%20PDFs/T5557.pdf

http://ww1.microchip.com/downloads/en/AppNotes/Atmel-4980-RFID-Kits-Overview_Application-Note.pdf



T5577


T5567

EM4xxx
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


  • EM4100
125kHz
64 bits of ROM (of which only 40 are usable, the other 9+10+4+1 are settled via header, parity, and stop)
http://www.priority1design.com.au/em4100_protocol.html
http://www.priority1design.com.au/rfid_transponders.html
TK4100 seems to just be a manufacturer difference(verify)


  • EM4200
125kHz
128 bits of ROM (of which only 40 are usable, the other 9+10+4+1 are settled via header, parity, and stop)
https://www.rfidup.com/how-to-choose-lf-em-series-rfid-chip-em4100-em4200-or-em4305/


  • EM4205 / EM4305
125KHZ
512 bit read/write
(difference between EM4205 / EM4305 is purely in capacitance?)


  • EM4095
125 / 134.2 kHz
transceiver


  • EM4097
125 / 134.2 kHz
transceiver


  • EM4450
1 kBit


  • EM4550
1Kbit


  • EM4069
128bit
Unsorted proximity cards

NFC

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

For context, 'near field' is a generic term around EM that points out (roughly) that closeby, the wave behaviour works out a bit differently than at a distance.

...so near-Field-Communication (NFC) could have been general term for any shortish range communication (because of wavelength and/or transmit power),


...but it became a bit of a brand name for something more specific, usually:

  • based on inductive coupling between two antennas (simple, cheap, easy to miniaturize)
  • something that communicates with HF RFID (at 13.56 MHz, see ISO 14443)
  • ...often conforming to to ISO 14443 (proximity, ~10cm max range) or ISO 15693 (vicinity),
in the same context, RFID usually refers to quite varied systems mostly described by the older ISO 18000.


NFC (Near Field Communication) is often thought of as an extension to RFID.

Which is a little fuzzy.

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

...but sometimes, people mix the terms, so the best way to be sure is to figure out the specific use.


Variants

13.56 MHz

  • NFC-A (ISO/IEC 14443A) - delay/miller encoding
  • NFC-B (ISO/IEC 14443B) - manchester encoding
  • NFC-F (JIS X6319-4) - FeliCa
  • (NFC-C - 14443 Type C was proposed to be FeliCa but was rejected)(verify)
  • NFC-V (ISO/IEC 15693)


Android seem to mostly speak NFC-A, leave NFC-B optional (and Felica may be supported in theory but disabled outside japan?),

iPhone seem to speak more out of the box?



On range

Physics-wise, the above-described RFID / NFC can be designed to work up to a meter, but any specific antenna design may reduce that, to something like 20cm, <10cm, and other 'basically touching' numbers.


This is sometimes by design - e.g.

someone shipping boxes boxes will be a lot happier if it just scans the thing they're bumping their scanner into, not everything on the closet ten pallets.
Similar arguments go for security of entry cards
Similar arguments go for security of biometric passports


Anything designed for range like ~1 meter tends to be called vicinity cards .



"So what's the difference between RFID and NFC?"

While NFC protocols are based on ISO 14443 and (parts of) ISO 18092, in particular covering the physical communication, but the specific cards ICs are not(verify)

In the real world, you could say that NFC is a specific subset of HF RFID, and also that it's its own refined thing.

For example, looking at the Android NFC docs it lists:

NFC-A (ISO 14443-3A)
NFC-B (ISO 14443-3B)
NFC-F (JIS 6319-4), a.k.a. FeliCa[2] a.k.a. Felicity Card (e.g. used in Hong Kong's Octopus card). Was proposed to be ISO 14443 type C, but rejected as such
NFC-V (ISO 15693) - vicinity cards


A vaguer answer is that yeah, you can see them as roughly the same, but with NFC often points at the newer bits - because RFID by nature was only designed to identify things, not to e.g. do secure communication.


...for context: in RFID terminology

125..134 kHz is Low Frequency (LF), and most classical RFID did this
13.56 MHz is High Frequency (HF)
856 MHz to 960 MHz is Ultra High Frequency (UHF)





At the same time, NFC seems be the term people see most often, so it might become the popular name? In particular, phones with NFC tend to have

  • Reader/writer mode - interact with NFC(/RFID) tags, in practice often contactless smart cards
  • P2P mode - use it as a network link. Used e.g. by Android Beam.
e.g. phone at pay terminal, phone negotiating that it can get onto WiFi by proving it is physically at the modem i.e. inside, phone talking to a printer
  • Card emulation mode - pretend you're an NFC/RFID tag


-->

NDEF
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

NDEF (NFC Data Exchange Format) is mostly a protocol that lets you do certificate-based signing (asymmetric cryptography), so you can verify the origin's authenticity.


As it's intended to also work with NFC tags, the message and a signature record tends to be pretty compact, and may store little more than URLs or basic media (in MIME messages).


In practice, you'ld also think of the NDEF API in phones to actually send these. It'll read NFC tags data, try to figure out the type, and tell you


https://en.wikipedia.org/wiki/Signature_Record_Type_Definition#The_NDEF_signing_process

https://developer.android.com/guide/topics/connectivity/nfc/nfc

https://developer.android.com/guide/topics/connectivity/nfc/advanced-nfc


Android Beam and similar

Contactless smart card

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


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


I CODE

NXP I-Code

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


UHF

Animal chipping

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

See also:

See also


Electronic Article Surveillance (EAS)

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


EAS is what makes gates go beep when you steal stuff.


AM - refers to acoustomagnetic. The 'acousto' doesn't refer to the workings, but apparently to the lowish operating frequency (58kHz).

Often the are the plastic, thick-ish rectangles.

It's basically just a mechanical resonator sized to resonate at that frequency.

The test is whether it resonates at that frequency.

There are two strips in there, the second being a weak magnet. This both helps that resonance produce noticeable EM, and is how you can disable this tag: by demagnetizing that second strip, which means the response is much lower.

These can be reactivated, though I assume this isn't very common for practical reasons.


There are also EM tags, which are, though the means of detection


RF (often 8.2MHZ)

On solid items these are often seen as square stickers. Sometimes with a barcode, which seems to be a nonsense barcode(verify).


On things like clothing they may be inside a much clunkier thing, which may have their own tamper protection and means of removal, The physical side of that is often completely separate from the 8.2MHz tag it contains.


These are LC resonant circuits, commonly at 8.2MHz but there are others. (Presumably the gates do a reasonably sized sweep anyway, to account for manufacturing imperfections of the tag)


Deactivating these basically breaks the capacitor part of the LC circuit, either mechanically (puncturing it), or more practically and commonly, with an EM field at the same frequency, but strong enough that it causes the capacitor to short. (which is also why there's usually a warning to not put anything else electrical near there. It shouldn't interact with most devices, but you won't be able to tell until it already has) So no, these cannot be reactivated.


Note that some products are manufactured with tags inside.

Order of a few 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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Officially should be in the "dozens to hundreds of meters" category but in practice not so much.


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

Bluetooth continuously hops channels, to lessen the probability of consistent interference with other devices in that range (other bluetooth, and in particular also 2.4GHz WiFi) but because that medium is shared, busy areas still have congestion problems and the added latency, and latency jitter, that that implies.


Versions and speed

Maximum speed:

  • Bluetooth 1.x (1999, 2001, 2003) is 1Mbit/s in theory, ~700Kbit/s in practice
its mode/rate can be referred to as BR
  • Bluetooth 2 (2004,2007)
introduced EDR, which can reach maybe 2Mbit/s in practice
(2.1 added Secure Simple Pairing, which sped up pairing)
  • Bluetooth 3 (2009) plain is still that ~2MBit/s
In theory, Bluetooth 3 HS can do ~24Mbit -- by basically just handing over to 802.11 (roughly WiFi)(verify) -- but HS is not a mandatory part of the spec, and I don't think a lot of devices ever did this(verify)


  • Bluetooth 4.x (2010, 2013, 2014)
defines BLE (Bluetooth Low Energy, once marketed as Bluetooth Smart)
which is a different implementation of very similar ideas (more on that below)
which has lower power consumption than bluetooth 1 though 3 - at least at lower speeds
speeds like 125 kbit/s, 500 kbit/s, 1MBit/s in theory, but often order of 300kbit/s in practice(verify)
  • Bluetooth 4.1 added ability for devices to talk to each other (rather than only to hosts).
  • Bluetooth 4.2 increased payload size
  • Bluetooth 5 (2016)
mostly didn't change rates
Added BLE modes:
a 2 Mbit/s when at short range (maybe 1.4MBit/s in practice)
a 125kBit/s which can carry a little further (useful e.g. for sensors)


The first three are their own thing, which we might now call 'bluetooth classic' (they were also settled by IEEE, while 4 and 5 are settled by its own SIG)

Versions 4 and 5's BLE is a different and incompatible stack from bluetooth classic (different modulation mode, different link layer packet format), but was adopted into the bluetooth standard, and both stacks can coexist.

Bluetooth 4 and 5 allows (but does not require) hardware to support both BLE and classic.

the 4 and 5 stack call refer to the BR and EDR modes of classic -- so we now typically refer to them by that.


So while BLE is technically incompatible with classical bluetooth, a lot of BLE hardware can easily choose to support classic BR / EDR modes as well. Whether the code running on them actually does that will vary a little more.

Bluetooth range

Bluetooth defined classes which correspond to transmit power.

Class 3: 0dBm
Class 2: 4dBm (probably most common in mobile devices)
Class 1: 20dBm

More were added over time, e.g. Class 4 (-3dBm), Class 1.5 (10dBm).


Around classic

In Bluetooth classic, range was mostly limited by transmit power, so basically we said

class 2 is 10m,
class 1 = 100m,
class 3 is 1m,
class 4 is 0.5m,
class 1.5 is 20m.


Around BLE

This got more interesting around BLE, because it can get noticeably more range out of the same power (you might get 100m out of +4dB, and a few hundred meters out of +10ish, though this requires both specific hardware design, and good conditions), so now equating the classes with range is now fuzzier.


Notes:

  • various devices make a (fixed) choice in the tradeoff between range and battery life.
e.g. if designed use doesn't need more than 10m, then BLE allows devices to turn down transmit power - so range is the same but battery life is longer
  • because connection is two-way, you're effectively getting the shortest range between two connected devices
  • range is significantly lowered by walls. (like with WiFi)
  • If many devices choose to be shorter-ranged bluetooth, this may mean less collision/congestion with your neighbour's devices
but you don't really control this

Bluetooth latency in general

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Bluetooth as a lower level stack has inherent latency - like anything.

How much?


It varying with things like

  • packet size - larger packets may mean slightly more throughput (because less overhead), but take more time to send so mean slightly higher latency (basic network theory stuff)
  • congestion - it's in the same band as all other Bluetooth devices, WiFi, and some other things
  • Bluetooth version
as because BLE (4 and 5) is actually a completely different protocol stack (which is better for battery life but also cares about latency a little less -- assume 8+ ms(verify)); BLE GATT seems to do 15-30ms with easy spikes to 50ms(verify)
and recent versions introduced some congestion avoidance (verify)
  • profile
e.g. if you use a 'bluetooth serial bridge' you are actually using Bluetooth SPP (Serial Port Profile)
which seems to add at least 10-20ms(verify)


So,

  • some packets may arrive in maybe 3ms
...roughly the best case, that you can barely even guarantee under lab conditions -- you will not consistently get that when there are a bunch of other devices in the band.
  • it is fairly likely that the communication layer can move a packet to another device in perhaps 8ms.
you can be happy if you get a fairly-consistent average of ~5 to 10ms.
  • jitter - the variation in latency due to low level details
probably a few ms in general, may rise to perhaps 15ms or so with moderate congestion(verify)
if you use a channel for something that needs regularity, then jitter will end up adding latency
  • with more devices, bandwidth lowers and jitter rises


Which for most uses is still plenty fast.

And for a few (e.g. music production) can be annoying or even prohibitive:


Bluetooth latency around audio

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

tl;dr:

  • don't expect lower than maybe 20ms to work outside of lab conditions
  • don't expect lower than 40-50ms in real hardware
  • for designs that care more about avoiding stutters than about latency, expect that it might be on the order of 100 to 200ms
If you like Apple Earpods as a benchmark of Fancy™, the numbers are something like 270ms for first gen, 180ms for second gen, and 150ms for pro(verify)
  • mobile devices may add some more buffer themselves (and thereby latency) so they can sleep their CPU more of the time
  • Bluetooth is a relatively bad choice for low latency audio.
classical analog RF was basically instantaneous (...arguably more as a side effect than a design choice)


Audio isn't the smallest packets, so transmitting audio is going to imply a little more latency than that of the radio it's using, a little more so on lower-bandwidth bases like Bluetooth and BLE.


On top of basic delays, the larger issue is the jitter. In audio, regularity of the samples is crucial, and if audio data is later than scheduled, it's an audible gap, what we'd call choppiness or stutter (or, if it's right at the edge of working, perhaps crunchiness).

The easiest (and arguably only) fix is to buffer at least the amount of jitter you expect, and play from that buffer. As long as that buffer doesn't empty, you're fine.


The thing is that that becomes a game of statistics.

Maybe a 20ms buffer is fine in your home, but not in an apartment building.
Maybe 50ms is way more than you need, but maybe it still shits itself when passing ten strangers with a similar headset.

A buffer of at least 25ms would be a good idea, but it'd still fail under heavier congestion, Remember, bluetooth is in the same band as 2.4GHz WiFi, meaning even more devices that can butt in and increase the jitter.

And, because people are going to mind stuttering a lot more than a little delay, a lot of devices err on the side of larger rather than smaller buffers.

This has nothing to do with price, or technology (mostly), because it's a tradeoff involving with something fully out of your control.
So many headphones add a more comfortable amount of buffering, in the range of 50 to 100 to 200ms.


One trick that might make more people happy is to start with a smaller buffer increase it the first time it stutters. It'll stutter once or twice but then be fine, and end up being as low as your environment allows. Except gearhead gamers may not like that you now have varying latency, that it may end up with higher than it needs most of the time based on a single event, and that turning it off and on again sometimes helps latency.


Also, both transmitter and receiver might add buffers.

Say, smartphones may buffer a little more than general transmitters, so that they can sleep their CPU more of the time, saving battery.

And since neither side knows or controls what the other does, things can add up quickly, to rarely be lower than 50ms, and easily be in the 200-300ms range. Even 500ms isn't crazy to see.



The codec side of this muddies the waters even more.

People associate aptX with low latency, but note that aptX in the broad sense may only aim for 50-150ms, which is only barely better than bluetooth itself (aptX is non-standard).

Only aptX LL aims for 35-50ms.

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


So now, you might want a chart mentioning SBC, A2DP, various aptX variants, LDAC, mentioning both support and latency in that mode.

Because less than that is potentially handwavey -- we can do good quality and 25ms (but not at the same time, haha!).



How much do you need?


In most uses, people don't really care.

Say, when listening to music, what's it going to be late to?


For movie watching, you probably won't notice when audio is 30ms later than the video, that's one or two frames. You may unconsciously adjust up to to 100ms. More than 100 or 200ms starts to look wrong. (I've measured my transmitter+headphone setup at around 300ms, which is certainly visible when you look for it, though I can mostly ignore it)

One practical way to adjust for this is to delay the video by the same amount. Various video players can do this (e.g. press j and k in VLC). Various TVs can be told to do this. Often manually, and sometimes there's a feature to detect the delay automatically (e.g. iOS Wireless Audio Sync and many things like it).


When gamers consider themselves pro, they become millisecond freaks and will easily prefer wired headphones. You're not moving around anyway, so why care about a wire?

There are some other options,


Music production and recording is a more complex matter.

For some things it's doesn't matter at all - e.g. listening to the result of a song you're making, and you might like wandering while listening.

Matching rhythm requires delays under 5-10ms, which means bluetooth is out for most audio, and borderline okay for instruments. At the same time, physics gives you that much if your drummer is on the other end of a moderately large practice space anyway just for speed-of-sound reasons. But I guess you watch them as well to adjust for that, so it's potentially still fine.

Yet some tasks in music recording and audio engineering absolutely stand and fall with latency, and for those those you will grab your wired headphones (or analog RF wireless if you have them. They seem to not be made anymore?). Because no bluetooth wireless audio can be pushed to <5ms reliably.



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 some notes may come in maybe 20ms late, that messes up regularity and timing.

You can, like with audio, get more regularity with some more buffering, but that means bluetooth MIDI may aim lower, but just not be able to guarantee it.

It's also why you probably never want a bluetooth drumkit. Again, that kit isn't going anywhere during your performance, so just wire it up.


Audio

Headphones (and speakers)

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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).

These are low sample rate (8 kHz or 16 kHz), mono things, and sound like it.



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 supports various codecs, including lower-quality ones, and the devices may separately 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).


Beacons

On estimating distance

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

precision tl;dr:

  • error increases with distance. Don't expect much at over 10 or 20m.
  • It might be great to e.g. locate a device, but will never be a way of accurate measurement.


Since most Bluetooth stacks give you the RSSI of at least advertisement/scan response packets, it's possible to estimate distance to anything that actively gives you Tx power, including at least everything that advertises.


If you assume a lack of obstacles and free space, then then signal loss mainly just follows inverse square law due to distance.

So if you have previously measure RSSI at a known distance, then the distance to the device later, given RSSI later, is (proportional to)

pow(10, (reference_db - received_rssi_db)/(10*n))


Notes:

  • it's handy if you measure that reference db is at 1m, because that basically means the above gives meters (rather than some proportional thing)
  • n describes how easily the signal passes, and is a bit of a fudge factor.
  • accuracy decreases with distance
  • this is rough at best, for various reasons - see below.



However, there are many complicating factors, which together can easily contribute 10, 20dB of variation, and according inaccuracies in the calculated distance.


Some of them can be controlled for, e.g.

  • tx power - is actively reported by bluetooth (which means you won't estimate stronger senders as being closer and weaker as further away, as just RSSI would imply.


Some of them are unknowns but fixed enough that you can calibrate them away for specific sending hardware

  • antenna and other losses
For most devices you do not know the RSSI at 1 meter, even though you know the Tx power
for beacons you do, because they have been characterized and actively advertise a "RSSI at 1 meter" calibration-like thing
e.g. ESPresence says that if you use your phone, you probably want to do a "RSSI at 1 meter" calibration once.
...but that is manual work that you can only do when you control all hardware.


Some of them are unknowns but can be improved with a little data filtering or fitting

  • tx power granularity and amount of samples - if reported in 1dB resolution it's still somewhat sort of rough. Also, the variation
you can make this slightly better with some lowpassing


Some are unknowns with unknown variations you cannot really know, e.g.

jitter in dB of devices that are not moving may already be 5dB - that's sort of an upper limit
orientation (antennas are somewhat directional)
your hand around a phone, or your body between the devices, blocking a decent amount of signal
pockets/bags/purses
multipath effects
radio / channel specifics


http://www.davidgyoungtech.com/2020/05/15/how-far-can-you-go

https://stackoverflow.com/questions/20416218/understanding-ibeacon-distancing

Some lower level details

ATT, GATT

BLE differences

Advertisements and scans

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Advertisement

Advertisement are unsolicited packets that say "I am device X and I exist"

Devices do not need to do this all the time, or at all.


Advertisement interval consists of

fixed set interval between 20ms to 10.24 seconds in (16K) steps of 0.625ms
plus an automatic random 0ms to 10ms.


Because a device will receive see a subset of advertisement packets(verify), devices that want to be discovered reasonably quickly will stick under intervals of few hundred ms at most.

I see iPhones mentioned a bunch - presumably they look less often(verify), so aggressive 20ms interval is more useful if you want to be discovered quickly? [3] It will notice devices with longer intervals eventually.


You can save power

  • if your use case lets you be discoverable for a relatively short time - particularly convenient in cases you want specific-device pairing anyway.
  • ...and possibly still send out advertisemet, but much slower, when not in that mode


e.g. a checkout system with bluetooth PIN device not currently in use might still care to alert you when that device is out of range or off (and doing it from the device's side lets it sleep more), and it's perfectly fine at whatever the slowest interval is.



Scans

A passive scan refers to listening to above-mentioned advertisements.


An active scan sends SCAN_REQUEST packets, and expects SCAN_RESPONSE in response.

Such a response also tends to contain more information than advertisement packets(verify)



On pairing

Some terminology you'll find

Packets

Piconets

Serial module notes

(Note that classic bluetooth had a serial profile, BLE does not and relies on some custom-but-well-known extensions)


TI CC254x based

HM-10
CC41-A, BT05

BC417

HC-05, HC-06

BlueSMIRF (RN-42, RN-41)

Proprietary computer stuff (gamer or not)

UWB

order of dozens of or a hundred 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)


ESPNOW

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Frequency: 2.4GHz (it's piggybacking on a WiFi stack)

Bandwidth: lowish, we're abusing wifi frames with smallish max payload

Latency: 5+ ms, spikes to dozens of ms (verify)


You can see ESP-NOW as

using a ESP8266/ESP32 radio
to speak a dumbed down WiFi that doesn't need an AP or pairing,
so e.g. usable for ESP-to-ESP communication
and potentially coexisting with the regular WiFi stack (with some practical footnotes).


License-free sub-gigahertz

Radio frequency communication used for things like home automation, car remotes, some wireless mice and presenters, RF-triggered flashes in photography, and more - many of which need only one-way communication.

Such bands exist elsewhere, but the names and frequencies differ.

(Device designers may, internally, keep the radio part separate and modular, so that they can make a localized version by plopping in a radio module applicable to that region)


A subset of these are referred to as ISM bands, a US-centric term because it comes from its ITU Radio Regulations, for frequencies that were once reserved for industrial, scientific, and medical use, free of licensing (but still due to some basic restrictions - mostly power output (range) and duty cycle, largely to make sure products will play nice enough with each other around).

ISM is used as a near-synonym for these license-free bands, but the details are usually a little more interesting, because internationally, the precise bands you can use is something defined by distinct local standards, which also vary over time (e.g. we recently had part of the band used by wireless microphones taken over by mobile equipment).


The sub-GHz bands uses are mainly a few MHz of bandwidth(verify) around...

  • 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
  • 315MHz or 433MHz in most of Asia (verify)
  • 315MHz or 426MHz in Japan (verify)
see e.g. ARIB STD-T67
  • 433MHz or 915MHz in Australia (verify)



Many of these bands have multiple distinct frequencies/channels defined in them. This may mean devices may be tuned to a specific sub-ranges/channel, may well use different modulation.

Regulations may also limits lowish transmission power.

This is often more or less by design, to limit range and thereby significantly reduce interference from lots of dumb


Range for is limited by the lowish transmission power, and the often very small and simple antenna.

Simple devices are very short range (order of 20m).

Some specific designs may be defined for order of 100m, 200m, 1km.

See e.g. LoRa, some XBee variants




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 [4], often specifically:
    • OOK (the simplest and probably most common form of ASK)
  • FSK, Frequency shift keying [5], 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 [6], not used much


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



See also:


Speed, Line code, protocol

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[9] or something else where bit trains are unambiguous without strict timing.



Line code is the name for how exactly user data is coded at the physical level. This is often designed with the intended medium's properties 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. ...in that they aren't documented anywhere, and not necessarily compatible. They are often also basic enough that they are easy enough to interpret and imitate.

A good number of applications that do no more than "button makes lamp go click" 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. The way these ICs work may make it even easier to figure out.


Receivers tend to do automatic gain control (this is great for working with signals where you don't know the strength it will come in at - without this you would have to design or adjust for a relatively narrow range), which is one reason these protocols often send a preamble (a section of sending with no meaning), so that the receiver can take some time to adjust to each reception (such receivers often end up adjusting to maximum gain when they hear no transmissions, and adjust down whenever they hear something), without missing the start of packets during that process.

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 [10]
  • 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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


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

SiK

On range, walls, and antennae

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.



802.15

802.15 in general describes wireless personal area network (WPAN), which induces a handful of distinct things. See http://en.wikipedia.org/wiki/802.15


A lot of you will be likely looking specifically for 802.15.4, "Low Rate WPAN".

And possibly specifically zigbee.


802.15.4 ("Low Rate WPAN")

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Bandwidth is lowish - a few dozen up to maybe a hundred kbps real-world user-usable speed on 2.4Ghz (verify), ~9kbps on 900MHz (verify)

Latency: assume at least 2 to 10 ms, with dozen-ms spikes for larger packets (verify)

Range is ~100m in theory, some variants more, though in general you shouldn't count on more than two or three dozen meters - much like WiFi - also because it's constrained by ISM-like regulations on transmit power


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

802.15.4 is technically mostly just the PHY layer.

Higher layers are varied




Physical layer uses one of three bands:

  • Channel 0: 868 MHz (Europe)
  • channel 1-10: 915 MHz (the US and Australia)
  • channel 11-26: 2.4 GHz (Across the World)

It seems many devices choose 2.4.


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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


On protocols:

Protocol-wise, a device can speak speak bare 802.15.4, ZigBee, or one of many other things.


The raw 802.15.4 protocol is simpler for point to point, but most people will want something on top to do more convenience stuff for them - routing, meshing.

These are distinct protocols, and most are incompatible on the air.

For example, XBee also sees use of Digi's own DigiMesh.


And then there are Thread and Matter, which are wider standards than just ZigBee.


Devices in principle could be made to speak any variant over their radio, but their firmware may only come speaking specific variants, e.g. prefer zigbee over the raw protocol, or only speaking




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


  • 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 larger-scale networks (verify)
    • It seems you can mostly mix Pro with non-Pro (unless you use Pro's high security mode) (verify)



    • Talks to 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: [14])
  • 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. [15]


  • ZigBee Green Power (part of the ZigBee 3.0 specs)



XBee is... somewhat confusing.


Even within itself (partly from the fact that chipset, Xbee series, usable firmware and resulting protocols are all entangled) but also because it's not immediately clear whether XBee is an implementation of zigbee or 802.15.4, or its own thing.


XBee is basically Digi's own, Zigbee-based/related(verify) protocol

  • 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; the difference between Zigbee and Zigbee pro is not like the difference between Xbee and XBee Pro



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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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


Higher level protocols built on 802.15.4

ZigBee specific notes
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.
  • 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


Matter

https://en.wikipedia.org/wiki/Matter_(standard)


6LoWPAN

https://en.wikipedia.org/wiki/6LoWPAN

DigiMesh notes

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


On (Not) Talking to other modules

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


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). [16]
  • 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 ID you would always check.

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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


'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[17] 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 (802.15.4)

  • 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


802.15.3 ("High Rate WPAN")

802.15.1

Was where Bluetooth used to be when it was standardized by IEEE, now it's handled by Bluetooth SIG.

Z-Wave

Frequency: 800-900 MHz

(not to be confused with zigbee)


https://en.wikipedia.org/wiki/Z-Wave


ANT

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Protocol designed for the 2.4 GHz ISM band, simple protocol stack but considers co-existence at that frequency.

ANT might be introduced in comparison to Bluetooth, BLE, ZigBee, Z-Wave (also at 2.4gHz,and BLE also being low power).


Range is something like 30 meters in practice (up to 100 in theory)

slowish (dozens of kilobytes tops)

meant to be very low power,

and seems aimed at things like sensors and tracking,

and seems used e.g. by fitness equipment


point-to-point but also mesh?


https://en.wikipedia.org/wiki/ANT_(network)

ESB (nRF series)

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

nRF refers to a few series of ICs from Nordic

nRF24 (e.g. nRF24L01 is well known)
nRF5: nRF51, nRF52, nRF53
...there are more, but they are increasingly specialized
see also Electronics_project_notes/Microcontroller_and_computer_platforms#nRF24.2C_nRF51.2C_nRF52.2C_nRF53


Bandwidth:

nRF24 - hundreds of kbps; easily drops with distance(verify)
nRF5- (verify)

Range:

nRF24 - hundreds of meters in theory, but assume lower speeds(verify)
nRF5 - assume a dozen?(verify)

Latency:

nRF24 can be milliseconds for small packets, dozens of milliseconds for larger packets(verify) and assume it rises with distance
nRF5 is BLE-plus-other-things-depending-on-model, so assume a dozen+ ms


They are essentially microcontroller + RF SoC chips, and models vary e.g. on peripherals in the microcontroller.

The nRF24 can be seen as a transceiver with SPI interface, nRF5 series are could be thought of as nRF24 plus an actually programmable ARM Cortex -- which out of the box seems to focus on BLE. (verify)


Protocols:

nRF24 speaks
ESB ('ShockBurst Enhanced')
optional ANT layer on top (verify)
nRF5
BLE(verify)
varied high level 802.15.4?(verify)
ESB seems sort of discontinued/not officially supported with the nRF5 series, so communicating between nRF24 and nRF5 comes with footnotes

Kilometers or more

Wi-Fi HaLow

WiMAX

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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


LPWAN

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


LoRa / LoRaWAN

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Band: License-free sub-gigahertz (e.g. 433 MHz, 868 MHz / 915 MHz); some variations at 2.4GHz (verify)

Speed: up to ~50kbps, may be under 1kbit in some cases

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

Latency: Assume seconds. It's made for power, not speed.


LoRa refers to a radio protocol


LoRa PHY is a physical layer, and proprietary.

If you have a predetermined set of devices, you can have them communicate directly, without needing anything else.


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

If you want to a connect a set of devices in an area, you could use one or a few LoRaWAN gateways there.

If you don't want to think about that at all, you probably want to sign up for an existing LoRaWAN network.


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


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


LoRa security

this is a good read


Sigfox

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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(verify)


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

LTE-M

https://en.wikipedia.org/wiki/LTE-M

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

RC

Unsorted

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

https://embeddedams.nl/different-ways-to-connect-iot-devices-to-transmit-and-receive-data/