Gateway device

[tbowmo]

So, now that my first pcb is going into production soon, I have to have something else to play around with in my schematics editor :)

I have been talking a bit with @hek and @axillent about a gateway, which could bridge between wifi and mysensors network.

Current design ideas is as follows, specs are subject to changes

• Powered by standard USB wallwart
• USB onboard ATSAM MCU
• ATSAM D21J (32 bit ARM Cortex M0 MCU)
• atsha204 onboard
• external SPI flash (Will probably be exchanged for a SD Card reader)
• NRF24 connector (should support version with lna/pa)
• RFM69W connector
• Wifi module connector (esp8266) (As we have ported mysensors to this core, it's not that necessary any more)
• Ethernet module connector (W5100)
• Surplus GPIOs available on pinheaders. (MYSX common pinheader between other projects)
• Various LED's for status, communication, error, inclusion mode etc.
• A couple of buttons, in order to go into specific modes during operation (like inclusion)
• Battery backup for onboard RTC? (Not decided yet)

My initial thoughts are that the module should not be multi radio node (that is, both RFM69, and NRF24 at the same time). It's up to the end user to decide which radio to equip the unit with. The same about network connectivity, either choose wifi, or cable.

Please note this is still just a thought in my head (Initially planted by @hek ;))

Would anyone be interested in such a thing?

Documentation (this will always point to the latest files on github)
Kicad project files : https://github.com/tbowmo/MySensorGW
Schematics in PDF : https://github.com/tbowmo/MySensorGW/blob/master/MySensorsGW-schematic.pdf

[Salmoides]

One thing to keep in mind as you conceptualize this is packaging. For each option you provide (type of radio, style of radio, w/wo Ethernet, etc.) you complicate the design of the enclosure. When we build our own boards, we think of that as we do the layout. When you "hard code" the layout, but add several if-checks in the process, you should remember those of us who don't yet have a fancy 3-D printer. :disappointed: We still need to shoehorn the board into an available box.

[Anticimex]

@tbowmo I have also briefly discussed this with @hek and I think along the same lines as you. Having both RFM69 and NRF 24 options is actually a good idea. RFM69 also supports longer range (lower carrier frequency) and AES encryption (for us paranoid freaks). I am wondering if it actually would be possible to run them simultaneously. The gateway could keep a table of nodes using the "other" network in runtime and store it in EEPROM (similar to how it tracks nodes that require signing). I see no direct technical reason for the GW not to be able to juggle both RF solutions in a mixed network.

I am in the middle of a big internal debate with myself at the moment whether I should stick to my current gateway which I have built and continue the battle with sketch size problems and such or build me a new one.

I have also not yet designed a box for my gateway, so I am actually considering trashing it and start over with a bigger design.

Do you know if there are any Atmega1284s "breadboardable"? I did not have issues with my W5100 module which has SPI_EN available so I think I will stick to that and WiFi is for me more of a nice-to-have feature since my goal is to cover the home in nodes so my GW should be possible to place anywhere where there happens to be a RJ-socket available.

One thing that would be nice though is if the board could be powered with POE (Power Over Ethernet). That is I think definitely a selling point.

I also think that hunting size on gateways is less important than functionality. Most only have "one" and it can be tucked away from sight from "other parts of the family less technically geeky".
I would even consider adding space so that there perhaps is some prototyping space where future addons could be patched in.

@Salmoides The case design is depending on you personal build preferences. But since the base board will have a well defined range of supported modules and such, a range of suitable cases can be offered as well. An example would be one box that has cutout for external RF antennae and one that doesn't. Of course it is possible to bring out the drill, but it is prettier to have a customized case.

[tbowmo]

@Salmoides

I don't own a 3d printer either. it's a secondary thing for me (I'm not that much into mechanical design, I let others do that part :))

@Anticimex
It should be able to have both radios connected, yes.. But what about available codespace? (Ok, we've got 4 times as much space as in the 328p).

The 1284p exist in DIP style, http://dk.mouser.com/ProductDetail/Atmel/ATMEGA1284P-PU/?qs=K8BHR703ZXgaD0L1rKdwiQ%3D%3D Can't be any more breadboard friendly than that :)

The wifi option is actually @hek's idea. And if we are going to make a pcb, it wouldn't hurt to make it possible, if someone wants to use it.

I had briefly looked at PoE, but got scared away by the specifications for it :) Think that it's around 48V, and using special magnetics (if you are going to be standards compliant). So need a good switchmode stepdown converter from 48V to 5V. But as it's still on the conceptual state in my head, we might be able to find something that makes it "easy to implement".

Of course size is not that big an issue here.. But 5x5 is standard for small batch pcb's from many of the cheap china board houses. that's why I would aim at that size.

Prototyping area could be an option. Also was thinking about throwing in a sensors or two. Again, it's a concept that has to evolve a bit.. Getting inputs and let it sink in, in order to make an awesome board :)

[blacey]

@tbowmo said:

Would anyone be interested in such a thing?

Another great application of your talent and I would be very interested in several. Beyond my own personal needs though, I believe a prebuilt gateway will significantly lower the get-started barrier for new comers to MySensors. If someone can buy a starter kit that includes an extensible pre-packaged gateway and a few Mysensors-micro sensors :+1:, then he/she will be up and running quickly with the basics and well-positioned to forge their own sensors and actuators if they are so inclined. Effectively make MySensors more accessible to a broader community.

IMHO, we should also develop an enclosure that we "prefab" so the gateway is a finished plug-in-play product or at least a complete kit that one can assemble with a screwdriver. I would also include the standard Rx/Tx/Err LEDs for each radio. While my custom-built gateway has the "include" mode button, I rarely use it so we should decide if it is worth the BOM cost.

You may want to design the layout with an eye towards a future where the MySensors gateway board could be packaged with an RPI or BeagleBoard in a single enclosure so we could offer a complete MySensors HA Controller (controller + gateway in single enclosure) preloaded with one of the leading open source HA packages.

Finally, we can leverage the 4x program space to design the gateway software to make it as "plug-n-play" as possible (e.g. DHCP, discovery, FOTA, etc.)

Bottom-line: Love the idea and am aligned with @hek and @axillent in encouraging you to take this to fruition. ;)

[Anticimex]

@tbowmo said:

I had briefly looked at PoE, but got scared away by the specifications for it :) Think that it's around 48V, and using special magnetics (if you are going to be standards compliant). So need a good switchmode stepdown converter from 48V to 5V. But as it's still on the conceptual state in my head, we might be able to find something that makes it "easy to implement".

I have not investigated the field enough but there should be plug-and-play modules for this with the necessary regulators and stuff. Basically a submodule with the Ethernet bits and then you get your SPI interface, perhaps some IO and a 3.3/5V feed from it. It should not need any additional circuitry.
But of course, if you intend to stuff your own single PCB I guess it is another matter.

[tbowmo]

@blacey

For my own part in this, I don't need a GW that much, other than what I have now (arduino nano, and nrf24 with lna/pa). But I could do it because it's fun, and might help others out.

Anyway, it might take a bit more incubation time, to get a usefull GW up and running now, as the summertime is coming up, and other priorities are up. But still, I love the tinkering with pcb layouts

For the enclosure part, I think we should have someone else do that as I am not skilled in that area.

And yes, forgot about LED's / inclusion button.. adding that to the list in post #1

@Anticimex
Have been looking around, couldn't find any plug'n'play modules with compliant POE and spi output, do you have some links? The only PoE thing I have found during search today, is Ag9050-S. But that's only the power module, and not obtainable on ebay, aliexpress or the like.

I haven't decided what route to take yet.. Depends on what "we" agree on in the end, as this is going to be driven more by requests from the community.

[Anticimex]

@tbowmo
Yep, Ag9050 is probably a viable option. It is available from a Swedish retailer at least but I have not looked into how it can be integrated into a design.

[axillent]

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:

1. there is a placeholder on PCB to solder but assembling is not done for standard version (for example for atsha204)
2. 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)

[Anticimex]

@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 :)

[axillent]

@Anticimex optional or nor is a subject of discussion
we need a trade-off between functionality and production price

[Anticimex]

@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.

[axillent]

@Anticimex first of all you are the best candidate to contribute in a discussion for optional or not

[Anticimex]

@axillent Then remove atsha from the optional list ;)

[tbowmo]

@axillent

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.

[Anticimex]

@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.

[axillent]

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 connector

legend:

• 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

[Anticimex]

@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.

[axillent]

@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?

[Anticimex]

@axillent Signing backends takes up some program memory. If we want a secure OTA solution we have two options.

1. Bootloader has full signing capability and protocol management (bootloader gets larger)
2. 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.