Today I have been researching options for permanently marking Mesh Extenders with serial numbers on the housing, cables and PCBs. This is complicated by the tropical-maritime operating environment, and that the housings are to be made of poly-carbonate.
Poly-carbonate can't be safely laser-cut or laser-etched, because it gives off toxic and corrosive chlorine gas.
Tropical-maritime environments eat glue for breakfast, and abound in UV radiation to degrade everything.
So far, the best option I have found is to use a laser-etchable UV laminates, e.g.:
https://www.trotec-materials.com/laser-materials/trolase-metallic-plus/lmt-314-203-br-stainl-steel-black-0-8mm.html
With an appropriate glue.
They do supply them with either 3M 467MP adhesive tape, which claims to be good for polycarbonate, and tolerates high heat etc, or a similar TESA adhesive.
Otherwise, you can get the laminates with no adhesive, and then apply your own, such as Dymax 3025 or 3099, which seem like they should be stronger than the 3M or TESA options.
The laminates themselves are quite cheap, less than AU$20 for 30x60cm. Assuming 4x5cm labels, this gives a material cost of only about AU$0.25 per label (plus glue) -- much less than the cost of the housing. We will likely need one 4x5cm label and two 2x5cm labels, so that we can have safety labels on the insides, incase the one on the outside falls off some how.
For the PCB, we can just have a silk-screen white panel to write the serial number and manufacture date on using a permanent marker, so no great problems there.
For the D-SUB 25-pin cables, we are looking at a nice solution to get those professionally manufactured with a low-pressure over-mould process, for about $14 per cable, plus parts. I need to have a chat to those folks to see what our options are there for imprinting them with serial numbers during production, or failing that, whether we can laser-etch or otherwise mark those.
Monday, February 27, 2017
Tuesday, February 21, 2017
SPI microSD card on Atheros 9k
For the new Mesh Extenders, we want to use a microSD card for bulk storage, instead of a USB memory stick. This is in part because USB draws a lot of power just to run the bus (about 10% - 20% of the total power consumption of a Mesh Extender), but also because we have had a lot of reliability problems with USB memory sticks in Mesh Extender prototypes. Basically, they don't like being shut down suddenly.
Our preferred solution was to add a microSD slot to the Ath9k modules we are using (the Core Domino). However, we could not find any good sources on how to do this. First, we tried using the bit-bashing driver, which we did get working, however it was horribly slow (about 10KB/sec), and would routinely freeze or reset the Ath9k (possibly due to watchdog timeouts?).
The Atheros 9k does have an SPI interface which is compatible with microSD cards, however, after searching for people having used it, I couldn't find anything sensible. The main problem is that the 16MB FLASH that boots the Mesh Extender is also attached to the SPI bus, and so there is a need to arbitrate between that, and our microSD card.
After I had given up hope and was trying to make the bit-bash driver work, I accidentally found a page that described exactly what I wanted to do, and had some simple patches for OpenWRT CC to implement it. You just had to assign a GPIO to be the chip-select for the microSD slot, and all would be well. Unfortunately I had no spare GPIOs.
What I did have, however, was the chip-select line for the 16MB FLASH. Since I had only two devices, I suspected that I could just invert that signal, and feed it as the chip-select to the microSD slot. As hoped, this worked just fine.
The total changes were very small:
https://github.com/servalproject/openwrt/commit/1cfb77ccaf4fd6a5ef345ba599534a5ae26114df
https://github.com/servalproject/openwrt/commit/3133e6ed935bc4d7705f72e639519e39cafa711d
https://github.com/servalproject/openwrt/commit/034daf1f4c63c90b079e40da3f8529288ddc1a79
Note that while I didn't have a spare GPIO, this approach still requires that you assign some GPIO to be the chip-select line. I chose a GPIO that was not exposed on the board I was using. For many low-cost wireless routers, like the TP-LINK WR703N and friends, there are plenty of such blind GPIOs to choose from. Indeed, this microSD hack should be fairly easily adaptable to the 703N, MR3020, MR3040 and many other cheap Atheros 9331 (or similar Atheros parts) wireless routers, such as the very nice GL-AR150 and related family.
Update: I have spoken to the nice people who make the GL-AR150 and related devices, and they are taking a look at this for evaluation.
Our preferred solution was to add a microSD slot to the Ath9k modules we are using (the Core Domino). However, we could not find any good sources on how to do this. First, we tried using the bit-bashing driver, which we did get working, however it was horribly slow (about 10KB/sec), and would routinely freeze or reset the Ath9k (possibly due to watchdog timeouts?).
The Atheros 9k does have an SPI interface which is compatible with microSD cards, however, after searching for people having used it, I couldn't find anything sensible. The main problem is that the 16MB FLASH that boots the Mesh Extender is also attached to the SPI bus, and so there is a need to arbitrate between that, and our microSD card.
After I had given up hope and was trying to make the bit-bash driver work, I accidentally found a page that described exactly what I wanted to do, and had some simple patches for OpenWRT CC to implement it. You just had to assign a GPIO to be the chip-select for the microSD slot, and all would be well. Unfortunately I had no spare GPIOs.
What I did have, however, was the chip-select line for the 16MB FLASH. Since I had only two devices, I suspected that I could just invert that signal, and feed it as the chip-select to the microSD slot. As hoped, this worked just fine.
The total changes were very small:
https://github.com/servalproject/openwrt/commit/1cfb77ccaf4fd6a5ef345ba599534a5ae26114df
https://github.com/servalproject/openwrt/commit/3133e6ed935bc4d7705f72e639519e39cafa711d
https://github.com/servalproject/openwrt/commit/034daf1f4c63c90b079e40da3f8529288ddc1a79
Note that while I didn't have a spare GPIO, this approach still requires that you assign some GPIO to be the chip-select line. I chose a GPIO that was not exposed on the board I was using. For many low-cost wireless routers, like the TP-LINK WR703N and friends, there are plenty of such blind GPIOs to choose from. Indeed, this microSD hack should be fairly easily adaptable to the 703N, MR3020, MR3040 and many other cheap Atheros 9331 (or similar Atheros parts) wireless routers, such as the very nice GL-AR150 and related family.
Update: I have spoken to the nice people who make the GL-AR150 and related devices, and they are taking a look at this for evaluation.
Mesh Extender EEPROM-equiped cable work
One of the novel features of the new Mesh Extender, is that the national radio regulatory parameters will not be stored in the main unit, but rather in the power cable, as I have described previously.
This means that we can, the theory at least, have bunches of Mesh Extenders pre-positioned regionally (or even globally), without having to configure them for each country in which they will be used. Instead, we just need to have batches of country-specific power cables for them, or similarly, program sets of power cables for them, and then send those to the relevant country/countries.
It also means that we can deal with unfortunate regulations that require firmware be locked in some countries, by having the firmware lock encoded on the power cable as well.
To implement all this, we are using 2KB I2C EEPROMs, so that we can have quite a bit of information stored, and also re-program the cables from one country to another when the need arises.
We want the RFD900/RFD868 radio to read this information directly when they power up, so that they can set their radio frequency and TX power levels appropriately. This means it makes sense to have the RFD radio talk directly to the I2C EEPROM, rather than via the Ath9k CPU. A second reason for doing it this way is that we don't have enough GPIOs left on the Ath9k module we are using.
All this means that I needed to implement an I2C library in the RFD900 firmware, and as mentioned in the previous post, implement the SHA-3 hash function, so that we can validate that the parameters are intact, and have not been corrupted by problems with the I2C EEPROM.
I found some nice reference information about I2C, and apart from some challenges at getting the timing and protocol right, it only took a few days work to get to the point where I can now reliably and quickly read and write the EEPROM. This meant spending a lot of time staring at oscilloscope displays like this one.
For development, I wired up a little board with one of the EEPROMs to an RFD900, to simulate the wiring for the cable.
One nice little trick that we do to save power consumption, is that the EEPROM is powered directly from one of the GPIOs on the RFD900. If we turn that GPIO off, then the EEPROM is physically switched off, saving a (very) little bit of power.
For the actual cables, we have the pinout planned such that the EEPROM can be soldered directly onto the relevant pins of the D-SUB 25 connector, to simplify assembly and avoid the cost of a little PCB, something like this:
Bending the pins the right amount was a bit more work than hoped, but with practice (or a little jig) could be done quite quickly. This is mainly because the chip is quite a bit fatter than the pitch between the rows of pins. The pins are the same pitch as the pins within a row on the connector, however, so that aspect is fine.
This theme of simplifying assembly is, I am finding, a recurring one as I plan how to make something that can actually be manufactured, even in modest quantities. All manual steps need to minimised so far as possible. This means actually trying to do things, rather than just designing them. So half way through writing this post, I wandered downstairs and tried to solder one of these cables together. I succeeded eventually, more or less, but in the process realised that to just fit the chip onto the back of the D-SUB connector, two pins needed to be swapped around. For now, I have soldered it up with the temporary fix, until we can get this pin change made on the next revision of PCBs (which fortunately haven't been fabricated yet). You can see the resulting mess here:
This means that we can, the theory at least, have bunches of Mesh Extenders pre-positioned regionally (or even globally), without having to configure them for each country in which they will be used. Instead, we just need to have batches of country-specific power cables for them, or similarly, program sets of power cables for them, and then send those to the relevant country/countries.
It also means that we can deal with unfortunate regulations that require firmware be locked in some countries, by having the firmware lock encoded on the power cable as well.
To implement all this, we are using 2KB I2C EEPROMs, so that we can have quite a bit of information stored, and also re-program the cables from one country to another when the need arises.
We want the RFD900/RFD868 radio to read this information directly when they power up, so that they can set their radio frequency and TX power levels appropriately. This means it makes sense to have the RFD radio talk directly to the I2C EEPROM, rather than via the Ath9k CPU. A second reason for doing it this way is that we don't have enough GPIOs left on the Ath9k module we are using.
All this means that I needed to implement an I2C library in the RFD900 firmware, and as mentioned in the previous post, implement the SHA-3 hash function, so that we can validate that the parameters are intact, and have not been corrupted by problems with the I2C EEPROM.
I found some nice reference information about I2C, and apart from some challenges at getting the timing and protocol right, it only took a few days work to get to the point where I can now reliably and quickly read and write the EEPROM. This meant spending a lot of time staring at oscilloscope displays like this one.
For development, I wired up a little board with one of the EEPROMs to an RFD900, to simulate the wiring for the cable.
One nice little trick that we do to save power consumption, is that the EEPROM is powered directly from one of the GPIOs on the RFD900. If we turn that GPIO off, then the EEPROM is physically switched off, saving a (very) little bit of power.
For the actual cables, we have the pinout planned such that the EEPROM can be soldered directly onto the relevant pins of the D-SUB 25 connector, to simplify assembly and avoid the cost of a little PCB, something like this:
Bending the pins the right amount was a bit more work than hoped, but with practice (or a little jig) could be done quite quickly. This is mainly because the chip is quite a bit fatter than the pitch between the rows of pins. The pins are the same pitch as the pins within a row on the connector, however, so that aspect is fine.
This theme of simplifying assembly is, I am finding, a recurring one as I plan how to make something that can actually be manufactured, even in modest quantities. All manual steps need to minimised so far as possible. This means actually trying to do things, rather than just designing them. So half way through writing this post, I wandered downstairs and tried to solder one of these cables together. I succeeded eventually, more or less, but in the process realised that to just fit the chip onto the back of the D-SUB connector, two pins needed to be swapped around. For now, I have soldered it up with the temporary fix, until we can get this pin change made on the next revision of PCBs (which fortunately haven't been fabricated yet). You can see the resulting mess here:
Here is the whole thing with the nice $1.35 a piece IP65-rated connectors I found recently:
Apart from the pinout problem, it wasn't too hard to assemble, really, so I am encouraged that this could still work. I won't stop thinking about how I can further optimise the process, however.
What I haven't covered above is how I am going to protect the cable head, so that it is sealed etc. For that, I have been talking to the plastics manufacturing people who are helping us with the injection-moulded housing design. They have suggested we could fairly cheaply produce a tool for low-pressure plastic encapsulation of the cable, similar to what is used to produce serial and printer cable ends. Because it is low pressure, it is possible to use aluminium for the tool, rather than the hard tool steel that is required for the injection-moulded housing. Because aluminium is so much softer, it is quicker (and thus cheaper) to machine.
8-bit implementation of SHA3
We have need of a hash function in the Mesh Extender for the RFD900 radio to verify that the radio regulatory parameters it is loading from the serial EEPROM in the power cable have not been corrupted.
Taking a look at the current major families of hash functions, SHA-1, 2 and 3, it looks like SHA-3 is the best. This is not just because it is the newest (incorporating the latest advances in cryptography against known attacks, compared with SHA-1, which is showing signs of vulnerability), but because it is also relatively computationally efficient (compared with SHA-2, for example), and friendly for running on simple hardware.
I found a nice public domain implementation of SHA-3, and tried to pull that into the RFD900 firmware. However, it upset the compiler in a variety of ways. In short, the SDCC compiler really doesn't like 64-bit data types, and does horribly inefficient (and incorrect) things with them.
Result: I have worked through the implementation converting it to a byte-oriented implementation of the full SHA-3 hash. It correctly calculates the hashes of various test-vectors I have fed it. What is nice, is that the implementation is now quite a bit shorter and simpler, because I have removed some optimisations for 64-bit machines from the code. You can see the code here:
https://github.com/gardners/SiK/blob/MeshExtender2.0/Firmware/radio/sha3.c
https://github.com/gardners/SiK/blob/MeshExtender2.0/Firmware/radio/sha3.h
For very short input texts, I can calculate a SHA-3 hash in under a second, which isn't too bad, given the little 8051 CPU on the RFD900 board.
Taking a look at the current major families of hash functions, SHA-1, 2 and 3, it looks like SHA-3 is the best. This is not just because it is the newest (incorporating the latest advances in cryptography against known attacks, compared with SHA-1, which is showing signs of vulnerability), but because it is also relatively computationally efficient (compared with SHA-2, for example), and friendly for running on simple hardware.
I found a nice public domain implementation of SHA-3, and tried to pull that into the RFD900 firmware. However, it upset the compiler in a variety of ways. In short, the SDCC compiler really doesn't like 64-bit data types, and does horribly inefficient (and incorrect) things with them.
Result: I have worked through the implementation converting it to a byte-oriented implementation of the full SHA-3 hash. It correctly calculates the hashes of various test-vectors I have fed it. What is nice, is that the implementation is now quite a bit shorter and simpler, because I have removed some optimisations for 64-bit machines from the code. You can see the code here:
https://github.com/gardners/SiK/blob/MeshExtender2.0/Firmware/radio/sha3.c
https://github.com/gardners/SiK/blob/MeshExtender2.0/Firmware/radio/sha3.h
For very short input texts, I can calculate a SHA-3 hash in under a second, which isn't too bad, given the little 8051 CPU on the RFD900 board.
Thursday, February 2, 2017
Potential Mesh Extender Use-Cases: Farms
I was talking with a colleague about our plans for the Mesh Extender in farming, and realised that I couldn't find anything written down about our thoughts in this space, so I am going to fix that right now.
While we had been thinking about it for a while, the need for something to improve the productivity and competitiveness of family farms in remote locations here in Australia was really bought home to us by Craig from the Evening Star Caravan Park in Charleville, Outback Queensland.
Craig pointed out the cycle of decline in many remote towns caused by the shift from family ownership of farms to corporatised farming. Basically, family farms mean that there is an extra family in a community, with kids who need schooling, and more warm bodies who need health and other services.
Corporate farming tends to use less people, in order to maximise economic efficiencies. Unfortunately, this means that a town often loses a family or two in the process. Then there are less kids at the school, so the school might lose a teacher (and the teachers family). Then the hospital (if they are lucky enough to have one) loses a nurse (and the nurses family), because the population has reduced, and so on. At the same time, there are now less mouths to buy food from the local supermarket and stores, so they reduce the hours of their workers, which further reduces the money that they have to spend in the community and so on. Basically, the loss of farming families causes a continual erosion of the viability of these communities.
However, it isn't easy to run a family farm, when faced by the economies of scale and other efficiencies that corporate farming is often able to harness, including the use of information technology to remotely manage their properties, which are often very large -- upto 10s of thousands of square kilometres (although in the past the largest such operation exceeded a staggering 220,000 square kilometres -- or about the size of the entire UK).
Basically, it is much cheaper, and therefore profitable, if you are able to manage your property from a network operations centre or station homestead, instead of having to drive potentially hundreds of kilometres over rough station tracks. However, the communications solutions currently on offer to do this are either two simplistic, e.g., analog water tank level sensors, or are so complex as to require dedicated personnel, and are simply not maintainable by the family farmers, many of whom are in their 60s and 70s. Also, the systems are simply too expensive.
The simplicity designed into Serval from the beginning has the potential to change this, by making it possible to create remote monitoring and control networks that do not require any cellular coverage (about 2/3 of Australia has absolutely no cellular coverage at all), or incur the running costs associated with it. This is part of why we designed Mesh Extenders with "Internet of Things" like inputs and outputs -- although of course we don't need internet access, so it is really more "Mesh of Things" (MoT). We have already prototyped a simple MeshMS control interface to support this, so that a farmer could just subscribe or unsubscribe to alerts from a sensor by sending a text message to the sensor. Also, they would be able to do this from anywhere on their properties, instead of being tied down to a centralised control interface. This last point is not to be underestimated in its impact.
That is, we think we can make something which is 10x cheaper than many of the existing solutions, and 100x simpler -- and that wouldn't need farmers to pay for expensive consultants to fly and drive in from big cities -- they could progressively deploy and maintain it themselves.
Of course, it isn't just Outback Australia that could benefit. Anywhere where the capital expense, availability (or affordability) of communications, or the lack of remote control and monitoring impairs the productivity of farms.
Basically, we hope that our humanitarian technology will be helpful in more than just one situation. In return, it might just help to create additional markets that can help us to reduce the cost of Mesh Extenders for all users.
While we had been thinking about it for a while, the need for something to improve the productivity and competitiveness of family farms in remote locations here in Australia was really bought home to us by Craig from the Evening Star Caravan Park in Charleville, Outback Queensland.
Craig pointed out the cycle of decline in many remote towns caused by the shift from family ownership of farms to corporatised farming. Basically, family farms mean that there is an extra family in a community, with kids who need schooling, and more warm bodies who need health and other services.
Corporate farming tends to use less people, in order to maximise economic efficiencies. Unfortunately, this means that a town often loses a family or two in the process. Then there are less kids at the school, so the school might lose a teacher (and the teachers family). Then the hospital (if they are lucky enough to have one) loses a nurse (and the nurses family), because the population has reduced, and so on. At the same time, there are now less mouths to buy food from the local supermarket and stores, so they reduce the hours of their workers, which further reduces the money that they have to spend in the community and so on. Basically, the loss of farming families causes a continual erosion of the viability of these communities.
However, it isn't easy to run a family farm, when faced by the economies of scale and other efficiencies that corporate farming is often able to harness, including the use of information technology to remotely manage their properties, which are often very large -- upto 10s of thousands of square kilometres (although in the past the largest such operation exceeded a staggering 220,000 square kilometres -- or about the size of the entire UK).
Basically, it is much cheaper, and therefore profitable, if you are able to manage your property from a network operations centre or station homestead, instead of having to drive potentially hundreds of kilometres over rough station tracks. However, the communications solutions currently on offer to do this are either two simplistic, e.g., analog water tank level sensors, or are so complex as to require dedicated personnel, and are simply not maintainable by the family farmers, many of whom are in their 60s and 70s. Also, the systems are simply too expensive.
The simplicity designed into Serval from the beginning has the potential to change this, by making it possible to create remote monitoring and control networks that do not require any cellular coverage (about 2/3 of Australia has absolutely no cellular coverage at all), or incur the running costs associated with it. This is part of why we designed Mesh Extenders with "Internet of Things" like inputs and outputs -- although of course we don't need internet access, so it is really more "Mesh of Things" (MoT). We have already prototyped a simple MeshMS control interface to support this, so that a farmer could just subscribe or unsubscribe to alerts from a sensor by sending a text message to the sensor. Also, they would be able to do this from anywhere on their properties, instead of being tied down to a centralised control interface. This last point is not to be underestimated in its impact.
That is, we think we can make something which is 10x cheaper than many of the existing solutions, and 100x simpler -- and that wouldn't need farmers to pay for expensive consultants to fly and drive in from big cities -- they could progressively deploy and maintain it themselves.
Of course, it isn't just Outback Australia that could benefit. Anywhere where the capital expense, availability (or affordability) of communications, or the lack of remote control and monitoring impairs the productivity of farms.
Basically, we hope that our humanitarian technology will be helpful in more than just one situation. In return, it might just help to create additional markets that can help us to reduce the cost of Mesh Extenders for all users.
Subscribe to:
Posts (Atom)