Gateway device
-
I propose to get step back and to agree first of all on the goal.
Discussing technical staff is a second step as soon as we clear on the goal.I see the following requirements:
- required minimum 128k flash
- required minimum 4k RAM
- required minimum 4k EEPROM (integrated or on board)
- required maximum performance (16 or 20MHz in case of atmel AVR8)
- required NRF24 interface
- required ethernet interface
- optional RFM69W interface
- optional wifi interface
- optional RF433 receiver/transmitter interface
- optional atsha204 on board
- required serial UART/USB interface (for debugging, download, as a configuration terminal)
- required two buttons
- required 3 leds (Rx/TX/Status)
- optional GPIO connector
optional/required is a subject of discussion
optional can be of two types:- there is a placeholder on PCB to solder but assembling is not done for standard version (for example for atsha204)
- all needed GPIO are available on the universal GPIO connector, but an external connection is required to connect extension (for example "required WIFI" means that PCB has a special connector for WIFI module while "optional WIFI" means that there is no special connector but a generic GPIO can be used to connect WIFI)
-
@axillent if atsha is optional, I pull out from the discussion. That makes the project irrelevant to me. Of course you can proceed with it :)
-
@Anticimex optional or nor is a subject of discussion
we need a trade-off between functionality and production price@axillent Then I leave it to the rest of you to settle the matter. And I will weigh in if I feel I have something to contribute. But let me say it this way; without any security considerations, I will not have something to contribute. All in all, I see @tbowmo's starting point as a good foundation.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
-
@Anticimex first of all you are the best candidate to contribute in a discussion for optional or not
-
I think that I would prefer to make a connector for a wifi module, that we sugest to use. It doesn't cost extra to make the connector, opposing to just a row of GPIO's where people has to use wires to connect to other modules. Then people could just as well buy a Arduino board.
The required interfaces should also just be connectors to external modules, f.ex for the nrf module.. Instead of incorporating the wireless stuff on-board, I would prefer to make it an external module. Then it's up to people if they install the version with LNA/PA and external antenna, or the version with pcb antenna. Or if one is going with RF69 radios, then the NRF module might not be needed at all.
So in my opinion it should be a base plate where people can extend at will with whatever they want, but still with socket for suggested modules, so people can make a "neat" installation easily by plugging in external modules (where we might make some available together with our HW partner, or recommend specific modules as being compatible), without using a bunch of wires and make birds nests
@Anticimex
atsha204 is (from my point of view) mandatory to have.. the price is 0.5$, it doesn't make sense to make a version without, and another with. It will also help people starting out with a unsecure sensor network, and then move to a secure one when needed. -
I think that I would prefer to make a connector for a wifi module, that we sugest to use. It doesn't cost extra to make the connector, opposing to just a row of GPIO's where people has to use wires to connect to other modules. Then people could just as well buy a Arduino board.
The required interfaces should also just be connectors to external modules, f.ex for the nrf module.. Instead of incorporating the wireless stuff on-board, I would prefer to make it an external module. Then it's up to people if they install the version with LNA/PA and external antenna, or the version with pcb antenna. Or if one is going with RF69 radios, then the NRF module might not be needed at all.
So in my opinion it should be a base plate where people can extend at will with whatever they want, but still with socket for suggested modules, so people can make a "neat" installation easily by plugging in external modules (where we might make some available together with our HW partner, or recommend specific modules as being compatible), without using a bunch of wires and make birds nests
@Anticimex
atsha204 is (from my point of view) mandatory to have.. the price is 0.5$, it doesn't make sense to make a version without, and another with. It will also help people starting out with a unsecure sensor network, and then move to a secure one when needed.@tbowmo @axillent
I also think having connectors for the less critical (and often more expensive) components is a good approach. If the boards are delivered without those, cost is cut, and the client is free to populate it further as they do see fit. If demand is high, the modules could be included in the "package". It just cost some size.We were using this concept of "base plates" at my work a few years back and I loved it. It was eventually scrapped due to cost (wrong decision, cost went skyrocketing without them, and now Sony pay the price).
By having the option with connectors you are free to experiment a bit with different options. We could consider having a variant of this board adapted for R&D but at some point we cross into breadboard territory so we need to draw the line somewhere :)
Another advantage of having the sockets is that although you leave a few options open for configuration, you nail down the IO mapping and that helps keeping the firmware variants down.
Regarding ATSHA, there is a software variant of it so there is no problem mixing in a network. That said, it would be crazy not to include it in this design due to it's low cost. If a user does not need it, or thinks the personalization stuff is too complicated, they can just skip to use it. But the paranoid ones (hrrm) will have problems if the board does not at least provide a SOT23 pad where it could be mounted.
-
OK, a modification after discussion:
on board minimum 128k flash
on board minimum 4k RAM
on board minimum 4k EEPROM (integrated or on board)
on board maximum performance (16 or 20MHz in case of atmel AVR8)
special connector on board NRF24 interface
special connector on board ethernet interface
special connector on board RFM69W interface
special connector on board wifi interface
special connector RF433 receiver/transmitter interface
on board atsha204
special connector serial
optional on board USB<->UART
on board two buttons
on board 3 leds (Rx/TX/Status)
on board GPIO connectorlegend:
- on board means soldered on the board on main version
- special connector means a special connector soldered but functionality is a subject of an external module to be plugged in
- optional on board - a place on the boards for optional soldering
sense and drive
-
OK, a modification after discussion:
on board minimum 128k flash
on board minimum 4k RAM
on board minimum 4k EEPROM (integrated or on board)
on board maximum performance (16 or 20MHz in case of atmel AVR8)
special connector on board NRF24 interface
special connector on board ethernet interface
special connector on board RFM69W interface
special connector on board wifi interface
special connector RF433 receiver/transmitter interface
on board atsha204
special connector serial
optional on board USB<->UART
on board two buttons
on board 3 leds (Rx/TX/Status)
on board GPIO connectorlegend:
- on board means soldered on the board on main version
- special connector means a special connector soldered but functionality is a subject of an external module to be plugged in
- optional on board - a place on the boards for optional soldering
@axillent said:
on board minimum 4k EEPROM (integrated or on board)
Not SPI flash? We will probably need a external flash if we want to have secure OTA. The alternative is to have a larger bootloader.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@axillent said:
on board minimum 4k EEPROM (integrated or on board)
Not SPI flash? We will probably need a external flash if we want to have secure OTA. The alternative is to have a larger bootloader.
-
@Anticimex we can add whatever we want)
explain me please the need of external eeprom
do you mean a support of OTA for sensor nodes or OTA for gateway itself?@axillent Signing backends takes up some program memory. If we want a secure OTA solution we have two options.
- Bootloader has full signing capability and protocol management (bootloader gets larger)
- Bootloader is kept as is today (as in how it works with @tbowmo s other board, and dumps new FW from external flash to internal on demand)
Option 2 is in my opinion the best way because it means not hacking around in the bootloader more than necessary. Updates in the protocol does not affect bootloader as well. Instead it is the "MySensor" library that manages signing and protocol for receiving FW, verifying it and programming the external flash. Once done it informs the bootloader of the new FW and reboots. A caveat is that this obviously means a sketch has to be downloaded to the device by wire initially, but I think that is acceptable. Especially in this case where FTDI and such already is in place (I would assume). Then again, the need for OTA on this type of device could be discussed further, but if we go for it, the mechanism should be identical/similar to the other "official" boards.
This is for OTA to gateway.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@axillent Signing backends takes up some program memory. If we want a secure OTA solution we have two options.
- Bootloader has full signing capability and protocol management (bootloader gets larger)
- Bootloader is kept as is today (as in how it works with @tbowmo s other board, and dumps new FW from external flash to internal on demand)
Option 2 is in my opinion the best way because it means not hacking around in the bootloader more than necessary. Updates in the protocol does not affect bootloader as well. Instead it is the "MySensor" library that manages signing and protocol for receiving FW, verifying it and programming the external flash. Once done it informs the bootloader of the new FW and reboots. A caveat is that this obviously means a sketch has to be downloaded to the device by wire initially, but I think that is acceptable. Especially in this case where FTDI and such already is in place (I would assume). Then again, the need for OTA on this type of device could be discussed further, but if we go for it, the mechanism should be identical/similar to the other "official" boards.
This is for OTA to gateway. -
@Anticimex what is a minimum external flash size is needed to support OTA for 128k MCU?
-
My initial fiddlings with schematics, I have already included a footprint for a JEDEC compatible spi eeprom/flash :) It's the same footprint, regardless if it's 512Kbit (as the one in my other board) or it's 4Mbit..
Regarding populating connectors or not, during assembly. I think that we only have the footprint for the different modules/radio technologies, that is no connectors are mounted! We could ship them in a kit, so the users have to solder them in by them self. This will allow the end user to assemble the connectors that they want to use for the specific application.
Another thought.. I propose that we add a standard micro usb connector, which can be used for power. People can then use a leftover phone charger wallwart to power the device. We could add a FTDI chip on board as well, and use the same USB connector for configuration. this of course depends on costs of the ftdi chip. (FTDI could also be a prolific usb <-> serial device, I am not locking us down to ftdi).
About the atsha204, the price is low, so I would add it. We are going to mounting it on the Micro sensor, so people can start using it. So why not on the gw? :)
I haven't looked at prices for different subsystems yet (like the usb to serial chip etc.) but might throw some hours at it tonight, trying to get an indication on stuff..
-
Is 16Mhz really a must have? The reason for my question, is that it seems that it would be more advisable to run the entire thing at 3.3V supply, as most of the peripherals that I have found, is running at that supply level.
That goes with : nrf24, SPI flash, wifi module, etc. So considering the peripherals I would suggest to run everything on 3.3V. However, this also means that we might have to lower the crystal frequency slightly, to 12Mhz, instead of 16Mhz, to keep it inside the specs.
Anyways, just a question. while browsing datasheets :)
-
Is 16Mhz really a must have? The reason for my question, is that it seems that it would be more advisable to run the entire thing at 3.3V supply, as most of the peripherals that I have found, is running at that supply level.
That goes with : nrf24, SPI flash, wifi module, etc. So considering the peripherals I would suggest to run everything on 3.3V. However, this also means that we might have to lower the crystal frequency slightly, to 12Mhz, instead of 16Mhz, to keep it inside the specs.
Anyways, just a question. while browsing datasheets :)
-
I agree. It is the center of the sensorweb. I think it pays to keep it running on full steam. And even if it is running of mains, and certainly is not suitable for battery powered operation, it still will draw a fraction of a lightbulb so hunting milliwatts makes little difference in the long runt I think. Besides, it will be bitter if we end up with performance limitations when we now "solve" the memory limitations.
-
well the reason to shift to 3.3v was that it would make things a whole lot easier, when interfacing with the different peripherals. It is not for hunting mA's.
But I'll dump some simple level shifting in there then.
@tbowmo ethernet/wifi/nordic at least are tolerant mostly to 5V
the only complication is to have two supplies
taking into account many different required things two supplies is not a major complication
while keeping arduino & atmel....but if shift to something else (stm32 for example) 3.3V are sufficient even for 72MHz
-
well the reason to shift to 3.3v was that it would make things a whole lot easier, when interfacing with the different peripherals. It is not for hunting mA's.
But I'll dump some simple level shifting in there then.
@tbowmo I see. But a simple stab to get 3.3V should be fairly cheap. And also "safe". I found that I could not get reliable RF on my Ethernet GW, so I threw in a LE33 just to power the radio (I use the PA-pimped one which is a bit more nitpicky on the supply). Have not had power issues since. So it could be that regulating the RF will be required anyway since I assume that PA-pimped radios will be part of the "offering".
