Gateway device

tbowmo

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

axillent

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

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.

tbowmo

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

Yes, 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.

RJ_Make

Looking Good!

marcusvdt

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!

tbowmo

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.

tbowmo

@axillent

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

axillent

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

if i'm not mistaken atmega644 (same family as atmega1284) is used in reprap and it is arduino too

plinioseniore

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.

tbowmo

@plinioseniore

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.

plinioseniore

@tbowmo

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.

hek

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.

plinioseniore

@hek

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.

tbowmo

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

MySensorsGW-schematic.pdf

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

Anticimex

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.

tbowmo

@Anticimex

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.

Anticimex

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

tbowmo

@Anticimex

Havent set any components as NM yet ;) just throwing components iñ at the moment

RJ_Make

I'm sure I missed it but..... as it stands this can be used as a serial gateway correct?

phil pritchard

@tbowmo

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

Gateway device

14

11.7k

11.2k

113.0k