@78RPM, sometimes the simple solution isn't as "exciting". My great pyranees is certainly up to the task of chasing away a wolf or two, makes enough racket that they will want to be somewhere else. Looks ferrocious too when she want to be. A great friend, protector and part of our family.
re PROBLEM DEFINITION -- whole post -- VERY MUCH AGREED! Many industries/verticals/etc have come to recognize the importance of approaching problem solving in a deliberate, methodological way -- I'm not saying methodoligical in the sense of 6sigma-level overhead, either; it can be as simple as combing the steps @elauesen enumerated (but following them deliberately and discretely). So, to give googleable terms for more info, I would try "design thinking" along with "systems-level" approaches (eg systems-level biology vs... anatomy) -- Essentiallly, I've gotten to the point where I try to approach...anything at all, really, from that type of perspective. I think it's very worthwhile for anyone doing anything, IMHO. (And please, if that long paragraph made no sense whatsoever to you, let me know, and I will clarify.)
@danlafleur, You are so right! And I have been telling people around here that that is the solution. Another solution is to get llamas - they are ferrocious defenders of sheep and their hair is valuable. But it seems like a lot of guys around here just want an excuse to shoot wolves. I want to reduce the need for blood-thirsty measures. You are spot on with sheep dogs.
i've seen a few posting about sheep management. what about low tech, get a dog. my dog is quite willing to tell the sheep to stop jumping around and if there is a predator threat, you will certainly hear her bark it away:-)
@WildDave You're absolutely right, but the IoT is forcing us to deal with 'frameworks' rather than a single standard. So if I stuff my size 12 foot into a glass slipper I can't go far (so to speak), so your point about 'flexibility' is critical. We have a lot of Cisco and IBM-trained technicians out there in the Universe who have to look beyond networking layers to solve packet loss in a jerry-rigged mesh
@elauesen Good point. But almost always the best design is to not limit the solution to a single problem but rather to design the solution so it allows for the most flexibility. That allows you to adapt the solution later for varied conditions that are unanticipated in the initial problem definition.
I just wanted to say that the most critical issue in any of this is PROBLEM DEFINITION. Often we jump into problems incrementally instead of doing ROOT ANALYSIS needed for a project. It would be a great lab to do some 'problem definition' exercises with the students. Create a 'simulation' and ask the students to come up with a clear 'project definition'. This is especially hard for engineers who are trained to solve problems one layer at a time. The IoT challenges us to look holistically at a problem before we commit to a solution.
@npitech, Gee, I hope I'm not monopolizing or abusing my time here. But what I want to measure is panic which would be told by a Vote of Accelerometers, not relying on one or two. Upon detection of panic, the central system could do anything -- turn on a spotlight, alert the shepherd in his bedroom, turn on a siren.
I think you need to think about sheep behavior. They tend to stay in groups and move together. I don't see a real advantage to having a mesh. If they were all over (like cows) there might be a benefit. In low power system, if two sheep were far from the group, a mesh does give you an advantage over a star. What are you tracking, their rate of change of travel, their location or a headcount? When faced with a predator they normally bunch. If they are moving over a large area how do you have a router? Will one or more animals carry a larger package?
@78RPM Sounds good. I'll check into that book. There is a legacy network protocol from IBM that they used in the dark ages called Token Ring that I've thought about borrowing some concepts from. It might be adaptable to mesh.
Yes, the ZigBee protocol is a good mesh - make all nodes full-function devices and they are all routers. Again, with the sheep I would make it a star if possible. You can do guaranteed time slots also.
@WildDave, I think you are correct in that every node can act as a router. I picked up an easy-to-understand book "Wireless Sensor Networks by Robert Faludi. It's removing many of my questions and is helping me set up some test networks.
I do find the sheep question interesting; wish I could offer something specifically useful, but...it would be kind of a holy grail of protocols (and every other aspect) working well in this type of "could be anything" situation, totally applicable to a multitude of other non-sheep contexts
?? Charles, Ooooh. So with 15.4 using collision avoidance, I don't have to use multiplexers -- which is what I was thinking. Now I just need to use a central node to tell all nodes to sleep for one second (using interrupts) and then wake up for a few milliseconds. This to save power.
@RWeber, each of those techs has their own advantages and disadvantages. Wifi is already TCP/IP and has range and bandwidth but is a power hog. Zigbee has cost of certification but has the best mesh network, enOcean has its niche, and zwave the lowest cost. There is no clear winner overall.
?? Charles and @miket. I want to talk about sheep again. Sheep move around and if I try to establish a mesh network or subnetworks, my nodes are all over the place. Help me think through a topology that might work to implement miket's idea of "summaries." Would this be multiple Star topologies? Would it be a mesh with some subnodes that have to look for a router node?
?? There appear to be four main competing wireless protocols: WiFi/IP, Zigbee, enOcean and ZWave. Which do you feel has the greatest stickness in the IoT and why? Are there any application areas where one excels over another?
@cghaba agreed -- and do you include what was previously called "M2M"? did that evolve into IoT? or... or are we just getting into a categorization exercise which will turn into a giant waste of time? :)
@elauesen Are you certain that most reimbursement related activities even need to be obfuscated? Because that's definitely not the way it's done now under HIPAA ...why do you think you'll be compelled to do that? (I suppose it's really -- HIPAA -- more about end-to-end security between "trusted" parties, with teh insurance company being one such party...)
re security via other layers like physical layer... of course, that's good when appplication-feasible. I suppose I tend to approach things from a very "paranoid" perspective, because unless you're working within a topology with a very very tight closed private network (eg not wifi, btle...) -- there nevertheless remains the data transport layer to whatever data warehousing system you're using... which, often can be on the public Internet. Then, I suppose with secure physical layer, you just have to concern yourself with your sensor network (etc) base station/gateway's pushing data for storage etc.
Security concern at the crux of doctor-patient confidentiality reconciled with accountability for billing is this: how to monitor examination and services provided by doctor while maintaining privacy and confidentiality. I have concieved of a time and motion concept that would link critical movement and equipment utilization triggers to a primary codex in an RPMS
For me, from my background, proper design entails using crypto for every instance you're transmitting or receiving data or control. Luckily, modern hardware is capable and inexpensive; it's no extra effort potentially (some more traffic overhead). (Though somewhat ironically, some of the 8-bit platforms I'm working with at the moment are [so far] coming up short there.)
I think there will need to be several different levels of security. Individual medical and financial data will always have a high security need. It seems to me that some individual messages may be partially secured simply by being anonymous.
Lauren, each day i have clicked on the play button of the audio as soon as it nas become available and each day it starts with you in mid-sentence. Perhaps you could wait a few seconds after sending out thelink before starting your intro.
Hi all -Audio is live! If you don't see the audio bar at the top of the screen, please refresh your browser. It may take a couple tries. When you see the audio bar, hit the play button. If you experience audio interruptions and are using IE, try using FF or Chrome as your browser. Many people experience issues with IE. Also, make sure your flash player is updated with the current version. Some companies block live audio streams, so if that is the case for your company, the class will be archived on this page immediately following the class and you can listen then. People don't experience any issues with the audio for the archived version.
@78RPM -- I comment you need proprietary ... hundreds of devices trying to communicate at once using COTS standards means almost none will be successfully received until stretched out in time (due to collisions and preamble requirements) using short range communications among the collars and a single collar to send "summaries" of the groups == better
Hmmm - I would look at the size of the pasture land. If the range is not too great, I would use the 802.15.4 protocol but not put ZigBee on top (not really needed). Plus, there are extra-rangle RF modules for that protocol (assuming 2.4Ghz). Look at Panasonic and other modules in DigiKey's catalog
?? @Charles, What if I want to put accellerometer sensor collars on a flock of sheep that would talk to a central MCU or computer. The MCU would decide whether sudden activity is just a playful sheep or a panic that is spreading throughout the flock -- a predator alert. What wireless protocol would I use? Zigbee?, Wifi?
The streaming audio player will appear on this web page when the show starts at 2 PM Eastern time today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser. If that doesn't work, try using Firefox or Google Chrome as your browser. Some users experience audio interruptions with IE. If that doesn't work, the class will be archived immediately following our live taping.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.