Gateway device
-
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
-
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.
We still need to shoehorn the board into an available box.
-
@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.
-
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
-
@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
, 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.
-
@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.
-
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.
-
@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.
-
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.
-
@Anticimex first of all you are the best candidate to contribute in a discussion for optional or not
-
@axillent Then remove atsha from the optional list
-
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
-
@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.
-
@Anticimex what is a minimum external flash size is needed to support OTA for 128k MCU?
-
@axillent The minimum size is decided by the maximum size of the permitted OTA FW.
-
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
-
@tbowmo gateway is kind of the bottleneck in mysensors network, I will prefer to keep a maximum performance
it is not a must, but i will say it is very reasonable
-
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
-
@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".
-
It's more the external SPI flash, I haven't been able to find any that works above 3.6V, where they specify abolute maximum voltage on any pin to be 4.1V. I haven't looked at the datasheet for ethernet / wifi modules yet, so there also might be some problems there with maximum ratings on input signals.
@Anticimex
I have already thrown in a 3.3V supply for the radio, and what else is needing 3.3V to operate.Anyways, I have thrown in a resistor / diode "matrix", to do level shifting on SPI signals now..
-
@tbowmo Did you consider using a ESP8266 WIFI Module?
You can easily program it and get the atmega off the part's list.How to directly program an inexpensive ESP8266 WIFI Module @ Hackaday.com
-
I fear that it will take too much time, if we have to port the library to the esp8266 cpu core. But you are more than welcome to dig in to it, if you feel for it
Currently the focus is (more or less) on arduino compatible platforms.
-
After finish my rpi gateway i think i will focus on the esp. I just wait for some local sellers to drop their prices(Easter, etc)
-
I've started using KiCad for this project.. Still it's far from completed (things are progressing more slowly with this one, than the last, as it's a bit more complex and I don't have that much time at hand now..
Anyway, I have created a github repository of it, if anyone wants to have a look, https://github.com/tbowmo/MySensorGW
Current schematics are here (PDF file)
MySensorsGW-schematic.pdfIt's still a Work In Progress.. A lot of stuff needs to be ironed out..
-
@tbowmo
Looks good. Perhaps add some header to break out a few I/O:s for future feature expansion? Like the SPI bus or i2c for a WiFi module or similar.
-
There will eventually be footprints on there for wifi / ethernet modules.. And Yes I2C should go to a pinheader. SPI is already at a pinheader (kindof). As it's connected to the ISP header
I'm trying to get a grip on my thoughts, and create some parts for wifi/ethernet modules..
-
So decision time..
For wired ethernet, it seems that we have 2 options:
- w5100
- enc28j60
I haven't got that much experience with theese devices, so which one should we go ahead with?
Wireless, I think that I am settled with esp8266, but if there are anything else out there, that might be better, then please let me know..
At the moment I can't really decide which one is better
So need some help from the community.
-
I use the W5100 on my current gateway, and I have not had any significant issues with it (apart from the infamous SPI issue, which is resolved by controlling the SPI_EN signal to the W5100. Apart from that I am happy with it, and it is intelligent enough to allow the necessary software to fit an Arduino Nano. Unfortunately not with DHCP enabled (and signing support enabled). But if the enc28j60 does not require more software, and handles SPI(?) "properly" perhaps it would be the better alternative?
-
Hmm.. seems that W5100 has a complete TCP/IP stack on board, where as the enc82j60 only has MAC hardware, so the tcp/ip stack needs to reside in the host controller.
So W5100 it is..
And ESP8266 for the wifi (so far)
-
-
@tbowmo thank! it is a good job done!
some questions/comments- w5100 SPI fix is already inside modern arduino ethernet shield http://www.arduino.cc/en/uploads/Main/arduino-ethernet-shield-06-schematic.pdf
do you think it is needed? what kind of the shield your are looking for? - why not to put 20MHz crystal to give some more performance to the gateway?
- USB is normally can supply not more than 500mA, are you sure it will be sufficient? DC-jack probably will be also good to have. ESP+wisnet could be hungry for the supply
- why atmega1284? it is not a standard arduino choice but could costs on a level of 1280. atmega128 is the lowest cost 128k AVR. If we are sure 128k will be sufficient in the future I will select atmega128 because of cost or atmega1280 because it is standard for arduino
And also I will consider atmega2560 to have a maximum possible resources (not only flash but also RAM)
- w5100 SPI fix is already inside modern arduino ethernet shield http://www.arduino.cc/en/uploads/Main/arduino-ethernet-shield-06-schematic.pdf
-
@axillent said:
@tbowmo thank! it is a good job done!
some questions/comments- w5100 SPI fix is already inside modern arduino ethernet shield http://www.arduino.cc/en/uploads/Main/arduino-ethernet-shield-06-schematic.pdf
do you think it is needed? what kind of the shield your are looking for?
I was looking at the cheap Chinese breakout boards with W5100 chip on, not all of them have the SPI fix onboard, so that's why I implemented it.
- why not to put 20MHz crystal to give some more performance to the gateway?
Hmmm.. think it was a price thing.. 16Mhz was more common than 20Mhz. But can't remember it right now (it's been a couple of weeks since I put in the 16Mhz xtal)
- USB is normally can supply not more than 500mA, are you sure it will be sufficient? DC-jack probably will be also good to have. ESP+wisnet could be hungry for the supply
In my thoughts, it should be either W5100 or ESP8266 mounted, not both at the same time (since both is for "internet" access. Also, most phone chargers are delivering 1A and up. Also, if you connect the thing to a computer via USB, you might not want to use W5100 / ESP8266 to communicate with it, so those power eaters could be left out in that case, leaving only NRF and/or RFM69 as radios.
- why atmega1284? it is not a standard arduino choice but could costs on a level of 1280. atmega128 is the lowest cost 128k AVR. If we are sure 128k will be sufficient in the future I will select atmega128 because of cost or atmega1280 because it is standard for arduino
There are some people that are using atmega1284 with arduino IDE, so it can be used. Solderability is the first reason: atmega1280 is 100pins, while atmega1284 is 44 pins, price: atmega1280 is 15.96$, while atmega1284 is 8-9$. Of course I can see the point in putting in 1280, as it could be swapped for a 2560 if more flash/ram is needed.
And also I will consider atmega2560 to have a maximum possible resources (not only flash but also RAM)
Atmega1280 is pincompatible with atmega2560, so they are interchangeable.
Anyways, this is mainly playing around with KiCAD, and creating something that might be usefull along the road :). Design is not locked yet, so I'll take a couple of iterations on it (just like I did on the sensebender micro, with selecting powersource, and sensor types).
- w5100 SPI fix is already inside modern arduino ethernet shield http://www.arduino.cc/en/uploads/Main/arduino-ethernet-shield-06-schematic.pdf
-
@tbowmo 20mhz should cost very similar to 16mhz, price is not an issue in this choice. Frequency is one of the parameter you will need to put inside boards.txt, it could be no issue to replace 16 by 20
ok I see. if soldering is an issue there is also atmega1281/atmega2561 pin compatible having TQFP64 package while been fully compatible with atmega1280/2560 (they do have single datasheet). Their maximum xtal is 16mhz
-
As I said, I can't remember why I decided on the 16MHz crystal... it could have been a decision based on baudrate accuracy. But I'm not sure now.
one thought, is the arduino spi library capable of using the extra spi ports on the atmega1280? (The 4 uarts can be reconfigured as spi ports)
Started debating with myself, the benefits of changing cpu
I'll look further at the data sheets.
-
@tbowmo I'm not sure that arduino SPI library can deal with USART as SPI at all
but it could be no problem to write down a peace of a new code to use USART as SPIwhy you need 5 SPI's?)
-
why you need 5 SPI's?)
Just a thought on versatility, that's all
you could have ethernet hanging on one SPI channel, and NRF / RFM on another, giving higher throughput (Ok, I know that it might not be necessary in this project at the moment..)Btw. just had a look at the datasheets for atmegas. 1280 / 2560 / 1281/2561 has 8Kb ram, while 1284 has 16Kb. Also operating frequency, 1284 is specified up to 20Mhz, while 1280/2560 etc. is only 16Mhz.
So many parameters to choose from
-
@tbowmo said:
giving higher throughput
ohh) the logic coming from PC world not working here. regardless how many SPIs you will initiate MCU will handle them in a sequence.
but any way it could be a benefit
for example you can avoid SPI fix if there will be exclusive SPI port used for wiznetSo many parameters to choose from
on other hand it is good. atmega644/1284 are from later generation having more features. 16k RAM is a very good thing, gateway potentially could be hungry on RAM usage. The disadvantage is missing 256k version
for last resort I will ask @hek to request quotes from partners to understand better the price difference.
-
@axillent said:
@tbowmo said:
giving higher throughput
ohh) the logic coming from PC world not working here. regardless how many SPIs you will initiate MCU will handle them in a sequence.
as they are in HW, they operate independently. So you can have two channels receiving at the same time, and another transmitting. The CPU just needs to put the bytes into the tx buffers, and pick up from the RX buffers.
but any way it could be a benefit
for example you can avoid SPI fix if there will be exclusive SPI port used for wiznetYes, when I started looking at the GW, I had in mind using multiple SPI ports just for this. I know that we can use Soft SPI, but i would rather have it as HW implemented as it would offload the MCU for handling the SPI signals.
Anyway, the SPI fix is a single gate that is placed on the board. the cost is at 0.5$ as far as I remember (mouser prices).
So many parameters to choose from
on other hand it is good. atmega644/1284 are from later generation having more features. 16k RAM is a very good thing, gateway potentially could be hungry on RAM usage. The disadvantage is missing 256k version
for last resort I will ask @hek to request quotes from partners to understand better the price difference.
I had thought about the same, asking our HW partners in china for the price differences.
-
Looking Good!
-
Can't say much other, than I'm excited to see where this is going... The only thing that I would like to vote for, is that you keep the atsha chip on board (not optional).
Thanks for your hard work!
-
I just ordered both ESP8266-01, and a W5100 breakout board, of the types that I think would be usable in this design (Both of them are available from iTeadstudio btw). Just to have some mechanical samples that I can measure dimensions, and connector placements.
So will wait for them to arrive from China.. I will also try to fit everything on one side of the PCB, right now I have an FTDI chip, and a capacitor on the backside (besides a footprint for the RFM69 pcb, which is up to the end user to mount).
ATSHA204 will be a mandatory part of the design anyways. We can just as well put in some security measures in our designs.
-
Just tried to create a new stanza in the boards.txt file, defining a board with an atmega1284p MCU. Seems like arduino accepts it, as I am able to use Serial1.begin(); in my code. If I switch back to compile it for a standard atmega328p target, it fails on Serial1.begin(). Also Serial2.begin() fails on atemega1284p target, so this indicates to me that it knows about this CPU from the beginning.
So from an arduino point of view, there is no problem in using atmega1284(p) as target device. (I haven't got one on hand, so can't do any specific testing besides trying to compile things).
-
@tbowmo sure
in general arduino can handle any AVR8 from atmel
my comment was about "not a standard arduino MCU" means it is not described inside official board.txtif i'm not mistaken atmega644 (same family as atmega1284) is used in reprap and it is arduino too
-
Hi,
this is my first post and I've pointed here by @hek while discussing of MySensor and Souliss (that is a project similar and different at same time from MySensor).
Just yesterday we got Souliss running on ESP8266 thanks to the porting of the Arduino cores on that MCU, this is an option that in my opinion you should take in account. The use of ESP8266 (and generally of all other) as WiFi to USART isn't impressive, I've never been in love with AT commands and I prefer binary communication compared to ASCII, but generally your AVR USART became your bottleneck.
Compared to SPI, USART isn't a master/slave protocol and the communication is driven by the transceiver, this is a really mess. When you use SPI, your low-RAM AVR decide when read data and this allow you to use the RAM of the transceiver as an external buffer, the tranceiver has mostly more RAM than the AVR.
While running over USART, the transceiver send data when want, so you should care on the AVR of buffering and process the frame only once is complete.More, the ESP8266 has multiple firmware release that doesn't provide a consistent behavior, so you end-up with a your own firmware to bridge data to USART. But once you need to program the ESP8266, you are just a step away to load on it the whole code.
Hope that this can help.
Regards,
Dario.
-
You got a couple of good points there.. So your advice is to find a SPI device for WiFi instead of the ESP8266 module?
Been looking for it, and only found CC3000 module, which (if I remember right) have problems with stability. Is there anything else out there that is affordable for WiFi connection, and usable from Arduino?
What I want in this device, is to have multiple connection methods, that is you can have nrf24l01+ for 2g4 sensor networks, rfm69 for sub 1Ghz sensor networks, and then choose between wired or wireless LAN connectivity to your controller (or serial, if that is wanted).
At the same time, we need to have security in mind, and support the standard authentication methods that is available for mysensors by now (using ATSHA204 chips).
I haven't looked that much at the ESP8266 as a platform thing, but it might be limited as a target platform, if we want to have all the different technologies connected.
-
Actually there is really no reason to still use AVR, while there are good reason to use Arduino. I mean, ESP8266 is a SoC that contains both MCU and WiFi radio, you can program the MCU directly and run on it what you need.
Actually there is a porting of Arduino (as core of libraries and methods) to the ESP8266 that is very stable and let you run your own code on the module itself, without have an AVR in between. The ESP8266 has also SPI hardware support, that can give you the way to interact to common radio like nRF24 or RFM69, even if some porting will be required to get the goal. Actually we have just ported Souliss and running over ESP8266 and is really working smoothly.
In terms of hardware there is no one good answer, mostly depends on your (and MySensor) architecture. The Souliss architecture support multiple bridge and routers, with RF and RS485 communication, so it makes sense for us to have nodes based on microcontrollers, this keep power usage and complexity low.
But if you have a start architecture (and probably MySensor has, correct me if I'm wrong) it may also make sense to move to OS based devices with an RF radio to join small and cheap microcontroller nodes.I know that design need a full stop, otherwise ideas storm far away from the goal. I'm just here to say that use a WiFi to USART device as transceiver for a 2Kbyte or 8 Kbyte RAM microcontroller is a bad design, and in my opinion non-WiFi RF may have short life in smarthome solutions.
What I saw in the three years running Souliss, is that further you try to automate, more likely you end up into a central point of decision, that is an OS based device. So you likely will be into a native WiFi or Ethernet device and this lead to use those technology widely, this is likely if you cannot run new cables. If you can run cables, RS485 looks still a good solution.
Regards,
Dario.
-
Thanks for the feedback @plinioseniore .
Yes, but still, isn't power consumption a bit too high on these puppies to use them for battery operated devices?
Last time I checked they were like 10x NRF. And I imagine powerup/reconnect time to a wifi network is much longer than the parts of a second we see for NRF24L01.Still it it would be very interesting to get the MySensors library up and running in an ESP! The more options the better. There isn't really any platform quirks or libraries used in the development branch.
For a ESP <-> NRF/RF69 gateway device, power consumption is not an issue. And I agree that it is bad that the USART communication is slow (and non consistent between versions) but it should still be able to shuffle around 70 (MySensors) messages per second at a moderate 19200 bps.
-
It mostly depends on what you need, as pointed before, my problem wasn't the USART speed it self.
But that I was no longer able to use the transceiver as a buffer, because is the transceiver to decide when send data over the USART, rather SPI as master allow the MCU to decide when get data.This is a problem with ATmega328 that has much less RAM that the transceiver that is attached to, but of course depends also on the average lenght of the frames that you over the air.
Dario.
-
Ok guys, I need some feedback before I start routing PCB again (for the 10th time :))
Could some of you please look at the schematics, and see if I have missed something? Also, I have made some design decisions lately, where I removed LEDs / buttons, and placed a pinheader for MMI. I have also added an extra pinheader for the unused GPIOs
Also, for refference, here are a 3d drawing of the current component layout.
It's designed so that antennas for NRF module / ESP8266 is hanging over the edge on the board (in the bottom of the picture), and W5100 board is having the ethernet connector besides the micro usb connector (which is top right of the picture). ISP programming header is located on the bottom side of the PCB, as it's only needed for initial development.
This is still a conceptual thing though..
So any comments, please?
-
KiCad FTW!
Looks good to me. I have been able to run the ATSHA SDA pin without a pull without problems but I do know Atmel recommends it so I guess it might be good to have. It should not need to be of any high precision so it ought to be cheap.
-
It doesn't cost anything to add footprints for extra pullup resistors, or decoupling caps. (Other than some time placing them). So I am throwing it in wherever I can..
I have sticked with 0603 components btw. So it should be easier to hand solder the first prototypes
The board is still 5x5 cm, probably being 4 layer so I can get room for all the wiring.
-
@tbowmo
Ah, did not see a no-mount indicator for it so I assumed it would be mounted by default. I agree on keeping all options open if space allows for it.
Yes, you probably have to go 4-layer on that. I had some trouble fitting the routs on my sensorboard in that space. And it has less components.
-
Havent set any components as NM yet
just throwing components iñ at the moment
-
I'm sure I missed it but..... as it stands this can be used as a serial gateway correct?
-
re: PoE supply
http://www.freetronics.com.au/products/power-over-ethernet-regulator-8023af#.VWCsPLmqqko
is cheap and easy you may be able to piggy back it on the board.
hope it helps
phil
-
@ServiceXp
It could be used as serial gateway, there's a ftdi chip onboard. But also place for Ethernet and WiFi connections, together with both nrf24 module and a rfm69 module.
Made to be as versatile as possible.
Ethernet is an add-on module, so a bit hard to implement Poe circuitry on this board. If we could find w5100 module with Poe, it might work.
-
Btw. Would it be an idea to include a sensor onboard? (Si7021)
-
I see no reason not to (depending on available space) add footprints for various "standard" sensors in addition to a IO header on the board. I have no idea on what impact it has on the sw to have a gateway report sensor values to "itself" but I see no reason for why that could not be supported (if it isn't already).
End of double-negations
-
What do you define as "standard" sensors?
-
@tbowmo
Perhaps an unfortunate label. I guess standard footprints would be a better word. I mean footprints for the most commonly used sensor cases. TO-92, DFN and etc. connected such as the typical sensors (1-wire temps and Si7021 like) will "fit".
-
Problem is that each sensor has its own pinout, so you can't make generic footprints.
There already is a GPIO header, with 8 pins (4 analog and 4 digital) plus power. So people can make their own daughterboards with sensors. Might convert 2 of them to i2c bus with pull up, and then have si7021 onboard.
-
Have you considered Grove plugs for sensors? This can give flexibility and a large enough number of sensors at a reasonable price.
-
Problem is space on the pcb
as I see it Grove connectors are big and bulky. I have placed a couple of pinheaders (one 8 pin, and one 12 pins) for external devices right now..
-
I think a header for daughterboards will go far in terms of flexibility.
-
updated the first post in the thread, with links to github project, and pdf of schematics (on github). So it will always point at the latest available one, so I don't have to remember that there is a forum thread to keep updated
-
Nice nice. I am very interested in this as I have more or less decided to swap to RF69 from RF24. Both for range and because I like the concept of having the radio handle the encryption on my signed packets (yep, I am paranoid as hell). Unfortunately, it means my current gateway has to go but I have made a "sensor evaluation board" (got the PCBs, still waiting for components). Once I get the components and can verify all the features I put on it I will publish it in this forum for those interested. It will still rely on Arduino modules and such so it is not the hard-core approach like the Sensebender Micro though.
-
@tbowmo
I believe you previously had the interrupt for RF69 connected. But it does not seem to be anymore. Any particular reason for skipping that?
-
I'm still rearranging things in the schematics, in order to get the best board layout :).
Could we go with one combined irq for both radio modules? (rfm69/Nrf24)?
/ Thomas
-
I see no reason why that would not work. I sure hope so as I did that on my board
Both radios will never be connected (or at least in use) simultaneously so it should be ok.
-
could be someone got brainfreeze and decided to go with both radios at once in one setup.. On the other hand, we're not using IRQ for the nrf24 at the moment..
-
@tbowmo
Even so, the electrical properties of the interrupt outputs on the module should ensure no meltdown occurs. And I think the user would get bigger problems than just having to figure out the origin of the interrupt
-
On the other hand, is there a usecase to provide HW interrupt functionality for a dagughterboard on the gateway? Since it will "by definition" have a solid power supply, any sensors using interrupts should be fine with the soft-interrupt options (have not looked into those myself though) or simply use polling. Power saving makes little sense in this case. The radios are probably better off with "real" interrupts (if we ever use them).
-
been fiddling with layout, and schematics changes..
Added a couple of MAX3002E for level conversion between 5V and 3V3 domains on the board. (Links to the schematic are in the first post of this thread)
Waiting for samples of the ESP8266, and W5100 modules, so I can make some last measurements before ordering boards.
-
Hi,
just want to share with you some of our progress in a board similar to the one that you are designing.
This is based on Atmega32U4 and has socket for nRF24L01 and ESP8266 and is designed to be battery operated and support Grove connector. The board has mosfet to switch off the sensor while sleeping and keep low the consumption, this should stand a year on battery.
We just received the PCB, picture at the link below,
http://www.souliss.net/2015/06/sensor-battery-board-pcb-arrived.htmlThe schematic and layout are open-source and hope that this board may fit some needs also in the MySensor community
https://github.com/souliss/boards/tree/master/Battery_Operated_Board/Ver1Regards,
Dario.
-
Looks like a nice board you have created... Only problem is, that we run out of memory on atmega328, if we want to run with signing and have MQTT client on board.
So that is why we have bumped the processor to a atmega1284 instead, having 4 times the memory, than atmega328. Also, with this board, we have the posibility to use both RFM69 and NRF24L01 on the sensor network..
-
Tried to make a concept drawing, of NRF module placement
the esp8266 is placed in a similar way, on the right edge of the board, also hanging over the edge with the antenna part.
the W5100 board (which is similar to this one from itead studio) is turned 180 degrees, which makes the ethernet jack placement above the large "empty" space on the board (there is a 2x3 pinheader in the concept drawing)
The micro usb connector will be just beside the ethernet jack. between the ether jack, and the single pinheader pin (this is the antenna connection point for the rfm69 you can put on the bottom of the board)
Things are still a bit conceptual, trying to visualize it for my self
-
I'll second (third? fourth? whatever...) the suggestion to design this to fit a cheap and readily available enclosure. Something like:
(Not saying that's ideal; just an example.)
-
the board is 50x50 mm, and with the radio / wifi protruding over the edge, this box should fit nicely.
The reason why I chose 50x50mm for the board size, is that it's either 50x50mm, or 100x100mm board when we order prototypes, which is more expensive. (And I like to make things small :))
-
Agree about smaller. Everything looks classier with less wasted space.
Probably too late now, but if the board had mounting holes that lined up with the enclosure that would be sweet. I'm always at a loss for how to keep my boards stable inside their plastic homes. Would love to hear peoples' solutions for mounting when the holes don't line up.
-
nothing's too late (yet). I haven't even ordered the first prototype batch yet. Still ironing out some details, and routing the PCB (I have only scratched the routing for the 10th time or so :s ). Actually I had thought about adding a couple of mounting holes in the board..
I'll see if the boxes that I have, resembles the one that I just linked to.. (I've talked with @hek about finding some enclosures a couple of days ago, when we suddenly found a seller on ali express, that only had enclosures of various kinds).
-
Yes the Atmega32U4 and Atmega328 has in the RAM their main problem, in our case we run smoothly in the 2KBytes available because we don't use ASCII in the protocol, but binary only.
Then the board is for as a remote sensor node, running on battery, not a main gateway board.
In any case, the board that you are designing will work nicely also with Souliss.
-
@tbowmo Mounting holes would be very good.
-
ok now with mounting holes. Or sort of.. the holes are 4.8cm apart, center to center, and the pcb is 5cm wide. I have used this case as a template.
-
and now with a w5100 module attached
-
very nice board, bravo !
thank you for sharing your work and knowledge.
-
Sweet!!!
Sign me up for 5!
-
You put a work into this board and it looks great. Cannot wait for it to come available.
-
@tbowmo My hat is off to you, for the major effort put forth along with @blacey ,@Anticimex , @axillent and @hek to name but a few.
While following this thread at times lost (mostly?) with explanations and concepts I have been learning which is half the battle.
It seems it never too late for a old dog to learn a little.
However it seems there is a need for a better gw from some of the threads I have read.
I for one will purchase a unit in what ever form it morphs into.Great work with all these boards.
-
I'm still routing the board, it's more complicated than my previous boards, so will be a bit longer process to get all in place.
-
A small update here, on an even larger update on the gateway device.
After some considerations, I have decided to switch the MCU for the GW to an atmel SAM D21G, instead of atmega1284. While doing this I have reduced the BOM for the GW, and cut about 1/3 of the BOM price.
The D21G is the same chip that's on the new arduino zero, and also on a kickstarter project called neutrino. @blacey is the one who pointed me in that direction
While being a more powerful chip (256kb flash, 32kb ram, 48 MHz, loads of extra peripherals) it is actually cheaper than the atmega1284, and it has build in USB controler, so the ftdi chip could be removed, a couple of other glue components is also gone now.
It will mean that we have to work a bit harder at getting mysensors running, but since the MCU is supported by arduino, we should be able to manage.
