RE: Meditech: Networking architecture

DAB — Wed, 12 Aug 2015 20:47:47 GMT

Great Blog.

At first your setup looked a little over complicated, but I can now see how much power it gives you for expansion and sensor options.

I also like the security arrangements, though you might have to look closely at any IOT sensors you add, they might open a vulnerability.

DAB

RE: Meditech: Networking architecture

screamingtiger — Thu, 07 May 2015 13:37:18 GMT

Cool project! A tri-corder was one of my ideas as well but I figured it may be hard to present a believable application, good job doing that!

Ethernet sounds like a good idea but the issue I see is you need a hub or router to connect everything together. Why not use WiFi or better yet, blue tooth so no router needed?

Then no wires are required to connect things together giving it a much better presentation. this is the future, and everything is wireless. In Star Trek, I don't recall anyone ever plugging wires into anything LOL.

I think your idea is fine and I wanted to just suggest wireless of some sort as I think it would be cool! Ok and my other motivation is I have a project I want to use Bluetooh for and would like to see someone else figure it out for me [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-78a10522-5350-4acc-abc2-090be28f4051/4667.contentimage_5F00_1.png:16:16]

RE: Meditech: Networking architecture

Former Member — Thu, 07 May 2015 03:49:25 GMT

Hi Enrico,

Once again, it's important that you use the system that you are comfortable in using and setting up. A big reason I chose that example block diagram is me thinking also towards how I would approach the ongoing security debate in the whole IOT scene.

By adding a security layer that uses a data transfer system that can only send / receive data that you want it to and also add open commands / data and secure commands / data that requires a password or even if the two devices are set up to share 1 password for a user session then secure commands could be encrypted with the password, sending an initial byte that tells the security layer that the next command is encrypted so needs decrypting before it can be interpreted.

Using this dual controller system where one is a gateway to the big wide world and the other operating a security and only communicating through an internal system would make a pretty robust solution. Of course, there would need to be work on the protocol and also encryption systems. Maybe the two devices could share another separate bus that the user has no access to. Allowing them to share encryption so each secure transfer can be encrypted with a unique key. Anybody who manages to hack through or brute force (lol!)the encryption on one packet of data can't use that same key for the others. (imagine how upset you'd be if you spent 3 weeks successfully brute forcing an encryption key only to find that it doesn't work with anything else...)

Correct, SPI bus can't send data a long way, the bus capacitance would definitely make high speed transfer untrustworthy. However, since the raspberry pi's are likely to be in very close proximity to each other, I personally wouldn't have any problem using SPI over the very few centimeters involved, using a fine well insulated solid core wire. The SPI bus over the short distance I expect to be between the rPi's shouldn't suffer excess capacitance-infact, it's likely to only be the distance that a standard PCB SPI bus travels for so the performance should be the same.

I'm not trying to change your mind :-) I just feel that anybody who reads and remembers that a SPI bus can only be used on a PCB might be limiting their knowledge.

*over short distances for board to board interconnects it's fine to use.

*over long distances like an external USB cable or cat5 run then don't use... ever...

The place that I would expect any delay is in the security layer that does the processing. It's got to read data in from one communications bus, possibly perform some post processing then send it back out of a different data port.

Like most systems that have a delay like this call it latency. I would expect this type of device to have some level of latency, It just depends on what is acceptible.

I hope you read the part I put on bluetooth. Having the ability to interfere with other devices would render this unusable around other medical equipment...

wow! another long post!

It's nice to read through your reasoning, but I wouldn't spend too much more time on it lol!

Lucie