'Hello!'

Once upon a time I had a colleague that consulted me quite often. I didn't mind that - I knew the systems concerned inside out and he was trying to market these things and thus he often asked what was and wasn't possible so it was part of my job to figure out answers to those questions so he could relay them out to customers and hopefully turn them to sales.

Approximately 98% of our phone calls were of this kind, so once I skipped the usual "hello" and answered his call (caller IDs were already the norm here so I knew it's him) with my best impression of friendly and smooth priest voice, saying "[Please] tell me [of] your problems." (I feel like a lot is lost in translation here, original Finnish was simply "Kerro huolesi"; "please" being implied with tone)

Line was quiet for a few seconds and then I could hear him laughing at the other end. My somewhat humoristic opening was received well. I felt though that this was phrase I could use only once so I never did it again, returning to more usual "hellos" and similar greetings.

Even these days I occasionally answer people I know with something less formal. Not something like above, but something else than the usual, somewhat formal answer with when I don't know who's calling. Not to mention something like "Hold on, I'll transfer to accounting" when, really, I just walk over to different computer.

But if you want to answer the office phone with something like this, you'd absolutely, positively need to know that the person at the other end can and will be willing to accept some humor in business setting. Not all people do, and almost no one does unless they have at least of passing knowledge of person answering the phone.

But if you really know that person calling can handle the humor like above - especially if they are a customer instead of colleague - then you're golden. They know that they can rely on you - and you know that you can trust them (well, as much as anyone can trust anyone in this modern dog-eat-dog world...)

Using chip Flash memories

Flash memories are pretty interesting chips. Note that here I mean actual, small flash chips placed on board, like this Micron chip. SD cards, SSD drives and such are very different beasts with their internal load balancing management modules. I mostly use chips with serial interfaces and have really no practical experience with parallel ones but many of the same rules should apply there too. There is also the reliability; for some reason I trust those small SOIC8 chips to retain my data way more than some random SD card.

Smaller flash memories cost almost nothing (one linked above being about 2€ in one-off quantities), come in nice, small 8-pin packages and are very easy to use over SPI bus, so it's very easy to throw one on your PCB for some extra storage as long as you have a few unused GPIO lines on the MCU.

There is some cost however. They are not the easiest memory chips to work with. You can't just freely change single byte or two within the memory; to do that you'll need to erase (wipe) one full sector (typical size being about 4 kilobytes), then write contents of entire block there again.

While that might not be too difficult, there is only limited number of erases you can do to a sector before it becomes defective - 10000 erases is fairly typical today, but it can be as low as 1000 in some cases. So by rewriting one sector continuously you'll wear out the memory very quickly. Unlike mentioned SD cards or SSDs there is no wear balancing - unless you do it by yourself.

So if you have some data that changes very often, you might want to pick some other memory type. But flash is very nice for data that isn't changing often - static binaries, configuration data, logs and such that needs only to be accessed and erased every now and then.

Similar intelligent load balancing as used by mentioned SDs/SSDs isn't exactly easy to do, as those is built to support random writes, transparent sector remapping and whatnot. However by designing your data usage pattern with minimal erase cycles in mind the implementation can actually be quite easy.

Note that above I said that you can't freely re-write any byte but must do that per sector basis. This, while true, isn't complete truth. When Flash sector is erased, bits within it are erased to all ones. All bytes to 0xFF. The nice thing is that any bit within a sector can be written to zero, at any time, without having to touch anything else. This small detail is often overlooked (and may not even work with all flash chips - test yours first), but it makes flash chips way more usable for many things.

So one way to implement incremental writes might be this:

You allocate, say, ten sectors for your data and start writing to first sector byte by byte, always to next untouched 0xFF. When you cross to a new sector, you first erase it (checking first if it needs to be erased is a bonus) and start writing there. When the last allocated sector is full, switch back to first one, erase it and so on.

There's of course a bit more to that, like reading entries in incremental order, resuming writes from correct position after power failure, allocating enough sectors so that erase count will not reach maximum specified on datasheet (or preferably, 80% of specified maximum over lifetime of your device) and so on, but they shouldn't offer too much trouble for clever hacker so I just mention those here in passing.

Many flash chips also offer additional features, like memory protection (both full chip protection as well sector bank protections), chip identifiers and such, so make sure to read the entire datasheet. There's nothing more frustrating than some write protection bit somewhere when you're trying to communicate with the chip, and typically chip-level write protects defaults on on when powered up.

The type identifier bytes also make very good test bytes; both when trying to get your code to work, and later when system is doing self-test. Can't read those constant bytes? Something's obviously wrong.

And now the flash chips should be way less scary beasts. Get a few and play around with them - low cost storage is always a nice thing to have. Happy hacking!

A few non-volatile memory types

Many embedded applications need to store some data in case of power outage, unscheduled reset or whatever. Reasons are various: program code, calibration values, serial numbers, current state, active log data, timekeeping, anything.

To respond to these wildly different needs a multitude of memory types has been developed over the years, starting from simple ROMs and ending... well, these days, Flash or MRAM are "best" (subjectively speaking), but who knows what we'll have tomorrow.

Different memories of course have different strengths and weaknesses. Some can't be written, some can be rewritten few times, some practically infinitely. Some are slow, some fast, some cheap, some expensive. Here's a quick overview of common types available today.

Let's start from ROM, due to being the oldest type. They aren't really common these days but for historical reasons I'll include them here.
ROM, or Read Only Memory, is just that - you can read but you can't write. Before cheap MCUs with large memory spaces became common they were often used for program data, LUT (Look-Up Tables) and whatever static data your application might need.

Main drawback of the ROMs is that they must be ordered custom-built from factory and thus have very high up-front cost; factory needs to tool their line to make your chips, which costs some serious money. On plus side, once that's done, they're very very cheap. Just hope you don't find a bug there...


Not every customer and every application can afford such a high up-front cost, so PROMs to the rescue (Programmable Read-Only Memory). These aren't really used used these days either but I'm certain they still are available for specialized or legacy applications. As the name says they can be programmed, typically with a special programming device. Chips typically are first programmed, then placed in headers on PCB. A bit of extra trouble there, but still a huge improvement over ROM process.

PROMs are one-time-programmable, so once programmed they're set in stone. A bug found? Discard chip and program a new one. But still a huge improvement over ROM process.

And they are still available today (kinda-sorta): For example Microchip offers their PIC processors as OTP ("one-time-programmable") devices - essentially they come from factory with your program in them. And they cannot be reprogrammed, ever, so for your application use they are PROMs.


Then there are EPROMs, E standing for Erasable (note, just one E there.)  They are programmed like PROMs, but they can be erased too. You can identify EPROM device easily as they have a "window" on top of the chip. To erase an EPROM they must be exposed to UV light, often in special "ovens", so if that's needed, the chip needs to be taken out from PCB, put in over for a hour or so, reprogrammed and then replaced. Not something that you can easily do on field, but then again, if you know that you'll need to do a field upgrade, you'd bring a replacement chip with you. This window typically is covered with a sticker when chip is in use to avoid accidental erase due to sunlight.

A huge improvement over PROMs, but still a bit clumsy.


Then there were EEPROMs, Electronically Erasable PROMs. Oh joy! These can actually be erased and reprogrammed even by your program on the PCB. The very first EEPROMs required high programming voltage that circuit needed to be able to provide; typically logic voltage was 5 volts and programming voltage about 12 volts. High voltage is needed to erase (reprogram) the device. If there was no need to erase EEPROM in application (treating them as ROMs) that could of course be left out.
Newer EEPROM chips have built-in boost module for that so external erase voltage is no longer needed.

EEPROMs are first memory type from these that is commonly used even today. Especially in smaller form factors (8-pin chips, with SPI or I2C bus) they are very very easy and cheap way to add some persistent storage to your project. Every byte in them can be (re)programmed individually, without affecting neighboring data, so small updates are simple to handle. Writing to them still needs to be done page-wise; typically you can write to a 64-byte aligned block a time, then you need to wait a bit when chip does its magic (rewriting) internally. Delay isn't much, few tens of milliseconds per page, but still needs to be applied for write process to work.

The main limitation (depending on your requirements of course) is that they have limited number of write cycles, typically 1-10 million erases. So if your data changes very often this might actually be a problem. EEPROMs come in limited sizes (again, I'm speaking mostly of smaller packages here); 256kbits (32kB) is already near the upper size that can be found easily, going above that will seriously limit chip availability. But in smaller sizes they are dirt cheap; single euro will buy you few kilobytes of persistent storage (note, I haven't verified today's exact prices so all quoted prices here are ballpark figures.)


Then came the Flash. I'm focusing to Flashes you place on PCB (like SOIC package) here, not SSDs or SD cards, as their data storage behavior is completely different.
Flash memory is cheap and much larger than EEPROM ever, but they have two serious drawback: First, they have limited number of erase cycles (can be as low as 1000 or so, 10000 being fairly typical), and they must be erased per-page: If you want to change single byte, you have to erase entire page (often 4kB) and write entire page again. I'll talk more about them next time as they tend to be a bit more tricky to use than EEPROMs.


Then there are newer EEPROM-like technologies like FRAM or MRAM (Ferroelectric Random Access Memory and Magnetoresistive RAM). And these are very very cool chips indeed. Persistent, byte-accessible memory like EEPROM with practically infinite erase cycles and no EEPROM paging limitations. Really, what is there not to like? Except price, of course. These bad boys aren't cheap; while 2€ will buy something like 64Mbit Flash chip, you might get some 64kbits of FRAM for the same price. But if you want to store small amounts of data that changes often, they definitely are worth their premium.


Also NVRAM needs to be mentioned here. I don't really consider them as persistent memories as term refers to small RAM that is backed up with a battery or capacitor. If the battery dies the memory is gone. I don't like them at all, but they are an option for some use cases - typical being an clock that needs to keep time even with system is otherwise powered off.


These are the most common memories available these days. There are others, often variations with names generated mostly for marketing reasons, or some less common ones, but knowing about these will typically suffice in most cases. And next time I'll talk a bit more about these Flash chips and how you can use them effectively.

Cars and electrical faults

My car (Skoda Octavia Combi) is now 5 years old and first electrical problems started appearing. Oh joy. In this case, it was the trunk opening button that went faulty. The lock there is fully electronic, the button is literally just that; button that signals the computer that someone wants to open the trunk. Opening itself is controlled by the computer.

So few months ago the button started acting up, not opening the trunk occasionally. Fortunately the car key (remote) has specific "open trunk" button that opens the trunk anyway so this wasn't acute problem as it was pretty cold out yet - working with cars in freezing conditions isn't exactly the most fun one can have outside. And remote button working indicated that it's the trunk button that failed, not the lock itself.

A few weeks ago now the trunk button stopped working completely, and since it had gotten warmer outside it was time to tear the trunk lid open and fix the problem. (or I could have taken the car to the shop, they would've fixed it and charged me something 200€..)

So I opened it. Unfortunately I didn't take any photos so text will have to suffice.

I found out that the button is a separate module, on first glance quite nice and tight-looking (IP44 or so on first estimate) package. The connector (two wires) however had oxidized pretty badly. So as a first resort I cleaned it up and put it back in. And it worked!

After a week I put the inner covering of the trunk lid back in.

And the damn think failed again on the very next day. Fuck.

At this point this would get very interesting with photos, but alas, still none...

On round 1 I was hoping to avoid any major rework of systems, but deep down I knew that oxidization usually can't be fixed that easily, which is the reason I kept the inner cover off for that long - I expected it to fail. So first thing was to scrap the oxidized connector completely and solder the wires directly to the button module.

No good. Button's completely dead.

So a closer examination of the button module itself was in order. And on closer examination I found out that the button isn't even close to IP rated as a module. Don't get me wrong - when properly placed in the trunk lid it still is protected from occasional splashes by its rubbery covering, but some moisture can still get in when in car wash or such. And when the button normally is enclosed within the lid the moisture will stay in and eventually start doing some damage (as a side note, I wonder if a small heater, in range of 2-5 watts, active when driving, would help there...)

After some careful destructive deconstruction I found that the button inside (fairly bulky) module is actually tiny, 15x5x10mm rectangle-shaped microswitch. I didn't have anything close to it handy, so I pretty much destroyed the plastic enclosure and replaced it with round one with about 1cm diameter I found from my dad's junk bin (main reason for not having photos; I wasn't at home.)  New button had to be glued and soldered in, of course. New button unfortunately isn't tactile so there is no "click" anymore, but who cares, at least it works! (for now, new button isn't any better protected against moisture)

Now, assuming the car still is in working condition years from now, I can only imagine some sorry future owner opening the trunk to figure out why button doesn't work and finding the -- umm -- innovative ways I fixed this. And I imagine that there will be some chosen expletives spoken that day...

Geiger counter from the 50s

Some time ago I managed to get my hands on an old geiger counter. For no reason, really, I just happen to like vintage tech stuff like this. Although this unit had been modified by someone at some point in the most unpleasant fashion.

The manufacturer is Atomic Research Corporation, and readout says "Model 521" on it. I can't find any absolutely certain information about this (the 521 models I see in net are slightly different, with hand-held radiation sensor; this one has the sensor fixed at the bottom), but so far the best guess places manufacturing date to mid-50s.

Does it work? I don't know. It takes few C-size (I think; might be D-size too) batteries which are no problem, but it additionally needs two 65-volt batteries of type I've never seen that - really - aren't exactly commonly available these days. This is where the modification done by someone comes in play; they attached a box full of 9v batteries in series to generate the high voltage needed by tubes. I consider that modification nothing but crude and vulgar and completely out of spirit of this vintage design and immediately removed it, without even testing if this thing works first.

 I've been thinking about building a boost or flyback transformer to boost lower voltage to more suitable levels, but I don't really have experience building such things (at this high boost factor, I've done boost converters with voltage factor of about 2 before) and so far all my attempts have been miserable failures.

Here is the insides. The large open area is for two 65v-batteries and on right you can see slots for two smaller batteries. Electronics on top is constructed in a fashion fairly typical of the era; everything just wired directly together. Not really most elegant or easiest to work with, but gets the job done. This isn't nuclear scien... oh, wait, it kinda is. Nevermind. Not complicated science though.

The sensing element (I think there is more accurate name for it but I'm too lazy to check now) is fixed on bottom, and there are few openings in the case for it. The crudely cut slots you can see there are for the wires to the battery box attachment. Ugly, ugly.

It even comes with full schematics! Unfortunately they are glued inside of the outer cover and have been somewhat destroyed by repeated removals and insertions of (fairly tight-fitting) insides so I can't get much better picture of them than this. Not very complicated thing as you can see. Unfortunately I have absolutely no knowledge about tubes and their operation so I can't even try to decipher how this is supposed to work. Maybe when (okay: if) I ever get my boost converted design working properly I can try to figure out more about the operation by trial and error, but for now it has to wait, just sitting there on my shelf on display.

Android 6 permission stupidity

Rant ahead.

Some time ago I got a call from a colleague who had problems trying to connect to our meters with a new phone; our app couldn't find any bluetooth devices anymore. During the discussion it became apparent that the new phone had Android 6 installed, first one I've encountered so far. So I started to suspect that something in new Android version might have changed.

Phone in question was across the country at the time so I had to resort to some internet searches by intuition instead. After a short search session it became apparent that to be able to find bluetooth devices apps now need (in addition to old BLUETOOTH_ADMIN permission that explicitly deals with bluetooth discovery) also ACCESS_COARSE_LOCATION permission. Now, this is just about the stu-- no, this is the stupidest thing I've heard this week. Hell, even this month.. Actually, make that two months, as this text has been sitting in my publishing queue for some time now.

Remember, like I just said there is already permission for Bluetooth discovery and pairing, the BLUETOOTH_ADMIN, so for limiting damage a rogue app could do adding this other does absolutely nothing.

The reasoning for this change apparently is that mapping out bluetooth devices nearby would allow rough geolocation, similarly to WiFi. Which is pretty stupid already - unlike WiFi, Bluetooth has very short range - 10 metres or so (granted, I've heard that newer (low energy) versions have improved the range somewhat - no idea how much really). Unless the surroundings is pretty much littered with searchable unmoving devices the search will be pretty much useless.
Most bluetooth devices are actually mobile and most of the time not searchable, so they aren't very useful for location purposes. You might argue that this is a way to inform user about this obscure positioning method, but I don't buy that argument.

But wait, it gets even worse. My app has absolutely no need for location information, ever. I haven't used any Android 6 devices (or even emulators) myself so I haven't seen the new permission system in action, but based on what I've read it asks for permission when it's used (although it seems that for apps targeting older APIs (read: vast majority of them, mine included) the system works as before - permissions are given on install time.)  As far as excuses for a features go, this is a pretty sorry one.

But for new apps -- I imagine that when user clicks "Find BT device" button a permission request for location pops up! User goes "WTF?" and clicks deny. And nothing works. And user has no frickin' idea what just happened (after all, he denied location, not bluetooth!), he only sees that the app can't find any any devices. Yes, the permission can be granted later (via app permissions menu), but first user needs to know that this menu exist and then also why that permission is needed, and I'd imagine that explaining why bluetooth need location permission won't be accepted easily by quite a few end users...

On the other hand, now a rogue Bluetooth-using app (that shouldn't need the information about location) can silently gather information about its (coarse) location any time it wants! After all, now pairing a bluetooth device within app explicitly requires location, so essentially this change made permissions worse. If there were an option to "allow these permissions for 10 minutes" (for the duration of pairing) this just might be acceptable, but it seems to be all-or-nothing (not many people go around changing app permissions after pairing, so that app permission menu doesn't count.)

One use case that might apply would be in-shop beacons (think of targeted advertising - when you're at product aisle you start getting ads for kumquats and whatnot) , but with all the other downsides listed here the new permission is much a failure with more drawbacks than help.

Overall this change is stupid, stupid, stupid. Android permissions have been way too vague for a long time, and this change only waters down existing permissions by shoving even more irrelevant crud to their coverage. What the hell were you thinking there, Google?


 

Soldering a DFN package

Many of the newest and coolest chips come in annoyingly small and difficult to (manually) solder packages, like DFN. For production runs this is no problem, but I typically prefer to assemble first boards manually - this allows me to catch stupid mistakes (like incorrectly set up regulator) without blowing up too many expensive components in the process. Manual assembly of course takes time, but at least you aren't paying 200€ each for five boards you immediately find out don't work at all due some stupid mistake that should've been caught at layout.

But back to DFN assembly. The following pictures are really crappy - I have to take them through my microscope's eyepiece, making it very difficult to focus them properly. I'll really need to get a microscope with camera one of these days...

So here is the situation. Chip in question is simple USB/serial converter. This one chip I salvaged from older board - finding problems is much easier when you have known-good (and properly programmed) chip already, allowing you to focus on problems on board itself. And there were a few such problems, as expected. But those are not today's topic either.

Like I said in previous post, I prefer to  use leaded solder for difficult jobs. This counts as one. So I got a small syringe of solder paste from local electronics shop (note; you absolutely must keep solder paste in cold, like fridge - it will be quickly ruined in room temperature!) and apply some on the board. The amount seen below is actually more than enough, about half of that would be sufficient. Adding to much paste will only result in shorts under the chip.

Then place the chip on top of the solder paste. Positioning doesn't need to be exact; surface tension will move it to correct place during soldering. I have cheap Chinese hot air soldering station with adjustable temperature and air flow. I typically set temperature to slightly below 300C and air flow to low value (about 20 on scale 0-100). Even then the air flow will easily blow chip away, so start from a longer distance and gradually get closer with the nozzle. Oh, and you absolutely want to have a microscope (or at least some magnification) for this - seeing what is going on makes the entire process so much easier.

After solder starts to melt, the chip will stay put and reflow properly. Don't try to hold the chip with a tool - this prevents it from settling properly during the reflow process.

No picture of the process, sorry (too busy soldering). Just the end result. Not the prettiest solder job, and needs some cleaning, but it works - which is all I need from a prototype board.

Wanted: Sharp multimeter probes

It seems that these days getting usable (read: thin and sharp) multimeter probes is almost impossible. All probe points are think, dull and sometimes insulated almost all the way to the tip. Apparently due to some stupid safety regulation or whatnot. If you only want to measure large objects this is (kinda) fine, but when doing prototyping or rework I often want to check shorts and connection of MCU or connector pins - and these days those tend to be with quite a fine pitch - 0.5mm or even smaller. For that these thick probes are completely useless.

But as usual, need is the driving force of invention: Thumb tacks to the rescue!

A bit unwieldy, yes, but at least now I can measure MCU pins without shorting them to neighboring ones.

Yet still, I'd still take proper long, thin and sharp meter probes any day. If I just could fine them somewhere...

Sometimes tools can be surprisingly expensive

Sometimes people being salaried (note; in Finland this means that monthly salary and work time are fixed; overtime is still compensated) seems to seriously twist the peoples' idea of how expensive time spent can be.

For example, at one time an engineer wanted to buy a small torque wrench for some reason but it definitely was work-related and justified (in my opinion at least). I don't remember the exact cost of the tool but it wasn't particularly high - something like 20eur or so.

So this engineer asked his boss for this wrench. Boss said sure, but he'd need to ask his boss in turn. So he did.

As a result there was a 30-minute ad-hoc meeting (not including above preliminaries) about whether this wrench was useful enough to be bought. Attended by three highly paid engineers (me included) and two even higher paid managers. If this had been billable meeting the cost would have been in neighborhood of 300€ (just a quick estimate, I don't know the exact costs involved).

That must have been one of the most expensive wrenches that were never bought.