For teachers
A bulletin board system is a small server that answers over the network and talks in plain text. This one runs on an ESP32, costs about $15, and a class can build, wire, house and operate one over five sessions.
It is a good teaching object for one specific reason: it is small enough to understand completely. A student can hold the whole system in their head, from the socket the caller arrives on to the file on the card the caller downloads. Very little else on a modern network is like that.
Everything below works on a classroom network with no internet access at all. Nothing here needs a port forwarded, and the section on school networks explains why that is fine rather than a compromise.
What it teaches
Each of these is something students can see happening rather than take on trust.
| Idea | Where it shows up |
|---|---|
| Client and server | One board, many callers. The words are roles, not machines: the same laptop is a client here and a server in the next lesson |
| Addresses and ports | The board answers on port 6400. Change it and nothing connects until the caller is told. Ports stop being magic |
| Text encoding | The board detects ANSI with CP437 or UTF-8, PETSCII, or plain ASCII, and draws itself differently for each. Text is bytes, and bytes need an agreement |
| Serial protocols | Four signal wires to the card, and XMODEM and YMODEM for transfers: blocks, checksums, acknowledgments and retries, small enough to trace on paper |
| Filesystems | FAT32 on the card because a laptop can read it, LittleFS on the chip because it survives losing power mid-write |
| Owning versus renting | The user list is a text file on a chip in the room. Compare that with any service the school pays for |
| Version control | The firmware is public and under the GPL. Students can read it, change it, and keep their changes |
What you need
- One ESP32 dev board per group. About $15 each. A board built on the ESP32-WROOM-32E is the tested one, and the tested boards page says which other ESP32s will and will not run it. Check before you order a class set.
- A USB cable per group. Often already in a drawer.
- One computer per group to install the board from, in Chrome or Edge, and a terminal program. There are free ones for Windows, macOS, Linux, Android and iOS on the terminals page. If your machines are Chromebooks, read the next section before you plan anything, because a Chromebook needs a setting turned on first and it may not be yours to turn on.
- Optional, for file areas and forums: a micro SD card module, about two dollars, a card of 32 GB or less, and jumper wires for four signal wires plus power. The parts are on the SD card page.
- Optional, for the enclosure: a 3D printer, or a print service, and a browser for TinkerCAD.
A board answers ten people at once, so you do not need one per student. For a class of thirty that means working in pairs or in threes, or running two or three boards and letting them compare. One board plus everybody's laptops is still a complete first lesson.
If your class is on Chromebooks
Check this before you plan the first session. It is the one thing that can stop session 1 dead, and it is not something you can fix on the day.
Chrome itself cannot call a board. No web page and no Chrome extension is allowed to open the kind of plain network connection telnet needs. So a Chromebook needs either the Linux development environment turned on, or the Play Store and an Android terminal app, and on a school Chromebook both of those are administrator settings that are usually off.
Test one machine yourself first. Select the time at the bottom right, then Settings, then About ChromeOS, then Developers. If there is a Linux development environment row with a Set up button, your fleet is fine, and the terminals page has the steps from there.
If the row is missing or the button refuses, it is an administrator setting, and a small, specific request that can be granted to one group of users rather than to the whole school. The terminals page names the setting and the value to ask for.
If the answer is no, find that out early rather than improvising in front of a class. A board on the classroom network is still reachable from any Windows, Mac or Linux machine in the room, and one machine on the projector with the chat room open is a perfectly good version of session 1 with the class taking turns at the keyboard.
Session 2 installs the board from a web page over a USB cable. Chrome on a Chromebook has what that needs unless an administrator has switched it off, but nobody has installed a board from a Chromebook here yet, so try one before the lesson.
Five sessions
Written as fifty minute periods. Session 4 is the one that usually runs over, and it is the one students ask to stay behind for.
Session 1: Call a board
50 minutes. Needs: one board already running on the classroom network, which you set up beforehand, and a telnet clientA free app for joining a board: it connects to the board's address and shows its screens., a free app for joining, on each machine.
Students connect to an address and a port, choose a handle, and end up in the chat room together. Give them ten minutes to work out that they are all typing into the same machine.
Then take it apart on the whiteboard. What is the address. What is the port. Which machine is the server and which are the clients. How does the board know how wide each caller's screen is.
Extension: have one group set their terminal to the wrong character set and look at the result. Text encoding lands much harder as a broken screen than as a definition.
Session 2: Flash a board
50 to 90 minutes. Needs: an ESP32 and USB cable per group, and the web installer in Chrome or Edge. No toolchain.
Each group installs the firmware, gives the board the classroom Wi-Fi from the same page, and reads the address the board came up on. Then they call their own board from the machine next to them. A group that wants to see the source turned into firmware can build it themselves afterwards.
The moment a group calls their own board for the first time is the lesson. Do not rush past it.
Watch out for: driver installation for the USB serial chip, which is the usual first-lesson time sink. Do it before the period, not during it.
Session 3: Wire the card
50 minutes. Needs: an SD card module, a card of 32 GB or less formatted as FAT32, and jumper wires per group.
Four signal wires plus power. Students wire it against the pin map, mount the card, and set up a file area.
Two things are worth stopping on. The module starts on 3V3, not VIN, and the page explains why, and the one kind of module that needs VIN instead. And the card is FAT32 specifically so that a laptop can read it afterwards, which students can prove by pulling the card and plugging it into a computer.
Then have them move a file onto the board and off again, and look at what XMODEM is doing: a block, a checksum, an acknowledgment, and a retry if it does not match.
Session 4: Design the case
Two 50 minute sessions, plus print time. Needs: TinkerCAD in a browser, which is free, and a 3D printer or a print service.
This is the session that turns a circuit board into a thing somebody owns.
Students measure their board, model a case in TinkerCAD, and deal with the constraints that make it a real design problem rather than a box: a slot for the USB connector, a window or a light pipe for the LED, or for a drive light and a strip if they are fitting some, somewhere for the card to go in and out, and a way for the two halves to hold together without glue.
The first print usually does not fit. That is the most useful part of the session, and it is worth leaving time to measure, adjust and print again.
Extension: ask each group to design for a different constraint. Wall mounted. Stackable. Fits in a pocket. Looks like it came out of 1984.
Session 5: Run it
50 minutes. Needs: the boards from the sessions above.
Each group becomes the sysopThe system operator: the host who runs a board, sets its rules and looks after it., the host, of their own board. They write the welcome screen, decide the rules, set who is allowed to do what, and look at the caller log to see who has been on.
Then the discussion that the whole unit was building towards. The user list is a text file on a chip on the desk. Nobody else has a copy. Nothing is sold, nothing is measured, and no company can change the terms. Compare that with any service the school pays for, and ask which parts of the difference matter.
About your school network
Almost certainly you will not be able to forward a port, and you should not try. That setting lives on equipment the network administrator owns, and on a school network the answer is going to be no for good reasons.
This costs you nothing. A board on the classroom network is reachable from every machine in the room, and every one of the five sessions above works exactly as written. The only thing you lose is callers from outside the school, which is not what the unit is about.
If a student wants a board reachable from the internet, that is a project for home, with a parent, and it is a decision for the adult who owns that connection. The page on what opening a port does is written for exactly that conversation.
Things to say out loud
- Telnet is not encrypted. Everything typed over it crosses the network in the clear, and the sysop can read all of it either way. (An ESP32-S3 board also takes SSHAn encrypted way of connecting to a board, beside telnet: what you type is scrambled on the way, so only the board can read it., which is encrypted on the way.) Students should know that before they type, and it is a better lesson in how networks work than any slide about it.
- Handles, not names. A made up name is the point. There is no reason for a student to type a real name, an address or a phone number into a board, including their own.
- Passwords are not reusable. If a board asks for one, it should be a password used nowhere else. This is worth saying every time.
There is a page written for students directly, at a reading level for about eleven upwards, covering the same ground in their own terms: a board of your own.
Where to go next
- Putting the firmware on a board: the web installer.
- Configuring it: the setup guide.
- The SD card: adding an SD card, with the pin map, a wiring diagram and what the card's error messages mean.
- Building from source: the build page.
- Calling a board: terminal software, on every platform a classroom is likely to have, including Chromebooks and what to ask for when one is locked down.
The firmware is free software under the GPL and the guides are under CC BY-SA 4.0, so a school can use all of it, change any of it, and keep the changes.