This is a really interesting post, let down by a vague title.
The author describes a system they created to help remote health centers in Thailand and Cambodia send disease cases in a structured way via SMS, while working around the difficulties of teaching people to send text messages in those languages (which have a lot of letters, often not made available on handsets).
Their solution was a cardboard disc wheel which could generate numeric codes that could be more easily sent.
The post is from 2010 - I'd love to read a follow-up on this project.
Did something similar in Africa 10 years ago. We created a whole human writable protocol, carboards to help, and you could control the systems using nokia 3310 charged on a car battery in the middle of the Dogon desert.
Fun times. Also, thanks python for making it way easier than it should have been. GPRS modems are not simple beasts.
Reminds me of various calculation tools used in, for example, grading school assignments (like circular EZ Graders). Or "feelie" anti-piracy devices from video games, back when they still came in boxes.
This is similar to what the military calls a "pro forma". This is a simple form with numbered blanks. You transmit the form name or number, and the values, as "1 - 105, 2 - 220, 3 - 3741 ...". Military units in combat send a "strength return" to higher headquarters each day, to tell HQ how many soldiers active/injured/dead, how much ammo they have, and how much fuel they have left. It need to be sent in a simple, condensed format. Visualize a sergeant in a foxhole reading those off over a radio. Someone at a headquarters summarizes those for the commander.
Here's a summary strength return prepared for George Washington in 1776.[1] The fundamental format didn't change a lot through at least Vietnam.
(Disclaimer: I work at Manas.Tech, partners of InSTEDD that developed the Reporting Wheel, although I haven't joined the company back when they did it)
Hi there! If you've liked the Reporting Wheel, you can see a couple of screenshots (and link to the source code) of the tool built to generate the wheels in Manas' site[0].
We work on lots of projects in unconventional contexts like this one. Feel free to lurk around the site and read our handbook[1] - and you bet we're hiring[2].
Spoiler: Essentially the author is talking about a custom encoding.
This is something I always try to impress to other engineers. Everything is just an encoding to binary. How we interpret it is entirely up to us. Even the fact that we choose to use 8 bits as a grouping.
Often this leads to much more efficient implementations...
But still data is stored in 8 bits. 9th bit holds information whether "byte" contains slave address or frame data. so that when slave listens and if it receives byte with 9th bit set and the rest is it's own address, then it can start to interpret following bytes. Otherwise it can ignore following data.
Maybe that comment is not so relevant to thread, but one may be curious how it works.
I'm amazed at the creativity and the simple-ness of this solution. Working in public health myself, we've often designed systems that became un-usable due to requirements in the field that cannot be met (people not having laptops/PCs or not knowing how to use them or Internet is missing, etc...)
Brilliant write-up, I'd love to know more about how many years this work went on for.
While it’s creative it’s not novel, these “computers” were very common not that long ago and are quite often still used in various applications such as engineering and architecture e.g. slide rulers..
Arabic notation / base ten seems to work really well with our brains. Having that many fingers probably helps. I couldn't imagine a modern world running on Roman Numerals.
I don't think the choice of base is really dependent on finger encoding efficiency. Going 0-5 on a hand has the advantage that we only really care about the "last" finger.
Anyway, if we really want to go crazy, the knuckle and first joint on (my, at least) fingers can be controlled somewhat independently, so I think we can fit in 4 states per finger:
In a base-10 system the explanation is as simple as holding up both hands and then holding up the number of fingers for each hand you want them to add. The kid can count and intuitively learn how to add up two numbers. It’s really simple and really efficient.
The idea of counting to 12 by pointing to knuckles is something I hadn't encountered before, and really neat.
Kinda surprised base-12 didn't end up dominating. Having so many factors would have made division so much more convenient for mental math, and it is only 2 extra characters to remember.
It occurred to me once that the big/little endian issues people have are really due to the conflict between Arabic numbers going in the opposite direction from English letters.
If both ran right to left, or left to right, then there would be no difference.
Most of us are programmers here, you are just as used to hex.
Also technically we don't have that many fingers. We have one more finger. We don't have a number digit for ten right? They go zero to nine. But out fingers go zero to ten.
If our numeric base matched our fingers, we should've used base eleven. Not many people think this through :)
I think the real breakthrough is having "order of magnitude" in numbers. So indeed the Roman Numerals suck and probably wouldn't last regardless.
Right. It lets you see the bits more easily: 0-F is a good representation of 4 bits.
Say i were to name a random hex value like #$9C right now it would take me a few seconds to convert that to decimal in my head though... 156 took me a few seconds to sort out. I don't have to think about what 156 means in decimal because i just know what it is.
I'm not quite there, but close to being bilingual (binumeral?) between decimal and hex, and I think it's all about developing better intuition for each digit and their relationships.
For instance, you say 0x9C... that's just over half (0x80) of 0x100, close to 2/3rds (0xAA). Given in embedded we're often using a byte to represent a quantity, that gives enough feel.
I should practice multiplying hex by hand, I reckon that would assist in getting there.
Replying to sibling since we've maxxed out comment depth...
> It was $62 degrees Fahrenheit yesterday. I can't just go displaying that in a program. Nor is it meaningful to me without a decimal conversion.
It's just as meaningless to me even if you do the conversion to base10 for display... I don't do deg F intuitively and would have to convert to Celsius in my head. It's all about what we are familiar with.
Right but the world runs on base 10 is all i'm trying to say. It's needlessly difficult to use anything else (aside from hex or binary in very specific situations). In some college sophomore philosophy class you could argue for base 27 but it doesn't make your system usable or intelligible.
> It's needlessly difficult to use anything else (aside from hex or binary in very specific situations)
Totally agree. I'm a programmer, so I do need to know those, and as an embedded developer, even more. The average person not so much. I thought that's what this particular thread was all about.
Sure, I can work it out, and I do use F when talking to friends from the USA. My only point was that I deal with hex numbers all day, so they're more intuitive to me than Fahrenheit is.
I think that under certain circumstances the reply link doesn't show past a certain depth, but you can still (unless the comment is dead) click on the time link to get the page for the comment and reply there.
It's interesting that octal used to be popular and isn't any more. I'm not familiar with how that culture shift happened, but I remember learning C in the 80s and thinking it was odd that it supported octal when I'd never seen it anywhere else.
I think their point is that we use our 10 fingers to count to a value of 10. We can use our 10 fingers to represent 0 (no fingers) through 10 (all 10 fingers). This is essentially base 11 if you try to assign a specific digit to each finger.
While I agree with that viewpoint I think it's missing the point. As humans with 10 fingers it's easy for us to group things into increments of 10, so base 10 comes naturally. Think about how you count a quantity over 10: once you run out of fingers you mark down (or remember) that you've already counted one quantity of 10, now you're counting the next quantity of 10, etc...
It's more like a shifted base 10 where we represent digits 1-10 instead of 0-9.
Everyone is thinking about a "shifted" base 10, yes.
But every base starts with 0, there's no such thing as "shifted base" because then you literally can't represent 0.
Also "zero fingers" is still a thing that exists in this shifted base 10. So it remains base 11.
This is like the classic "0-based indexing" vs. "1-based indexing" dilemma. The "first" thing is represented by 1, we think.
But the "first" year of our life, we're zero years old. The "first" hour after midnight is 0 o'clock. Building your "first" million as a business is the period before you have 1 million. And so on.
A base 10 with symbols only for 1 through 10, where zero is represented with an empty set is a Bijective Base 10 numeration. The columns in excel are bijective base 26.
It isn't that strange. Learning a language natively is an innate human trait that isn't regulated. The symbols we choose to represent for arithmetic (or to write the language, for that matter) must be learned.
The encoding used a prime number as a factor of the number reported, i.e. the ordinal number of each option is multiplied by that prime factor. The prime was selected as the largest possible number based on the max digits to send and the number of options to encode. That created a sparse distribution of possibilities, so that typos were more probable to get detected. It also enabled that by simply factoring the report and using the factors to identify the type of wheel that was sending the reports, allowing one single phone number to receive reports from multiple wheel types or versions.
SMS works really well in places that have poorer coverage / worse networks. That's partially because it doesn't rely on the 'data' coverage but fundamental telephony technologies that have been around much longer (https://en.wikipedia.org/wiki/Short_Message_Service_technica...). So basically if you have a signal of any kind, SMS will probably work reliably. Then there's the fact that you don't need any extra app or identity to use it. If you have a phone with a plan, you have no barriers to using SMS. Both these aspects are not as true for the software over Internet messaging solutions, and I think that's why SMS is still widely used and will continue to be widely used.
Back in 2003 I was chatting with a Dutch guy who was ragging on the US because we hardly used SMS. I guess we will eventually catch up to what the rest of the world is using now as they move on to something more spectacular.
«Customers who sign up for the M-Pesa service can convert between e-cash and real cash (these are called cash-in / cash-out transactions), and can transfer e-cash from their account to that of another account holder via SMS.»
To add some context, back when Reporting Wheel was developed the target audience mainly used feature phones. Even today, we run IVR and SMS campaigns instead in lots of countries (instead of using WhatsApp/Vibe/etc or even using a mobile-friendly web app) due to the smartphone penetration still being relatively low.
(I work on Manas.Tech, the partners of InSTEDD that developed the Reporting Wheel and today run nation-scale surveys using Surveda: https://manas.tech/projects/surveda/ )
SMS is fantastic. In my country there are a few popular messaging apps, it seems like to be connected to everyone you need to be on all of them; but you don’t, everyone already has a phone number, and it just works.
You can send hyperlinks if you want, so the medium isn’t really all that limiting.
The author describes a system they created to help remote health centers in Thailand and Cambodia send disease cases in a structured way via SMS, while working around the difficulties of teaching people to send text messages in those languages (which have a lot of letters, often not made available on handsets).
Their solution was a cardboard disc wheel which could generate numeric codes that could be more easily sent.
The post is from 2010 - I'd love to read a follow-up on this project.