Jump to content

Heath Raftery

Registered
  • Content Count

    46
  • Joined

  • Last visited

  • Days Won

    29

Posts posted by Heath Raftery

  1. NewieVentures, an electronic product development consultancy, is kicking goals and thus on the hunt for a talented electronics or embedded systems engineer.


    Join a small team to make a big impact. We turn ideas into products and no two weeks are the same. From our suite of Smart Parking devices to industrial power test rigs, you’ll get the opportunity to apply every facet of your technical knowledge while still exercising your vision and sense of value.


    Our particular speciality is in the Internet of Things and LPWANs, from PCB design to cloud infrastructure. We believe in life-long learning and doing what you love.


    Looking for 5+ years experience or the insatiable desire to gain it, for a full-time role in Newcastle West. Contact me at [email protected] or on 0431 909 116.

    Call for Engineers.pdf

  2. Fascinating project. You're really at the bleeding edge of Bluetooth so it would be beneficial to work directly with some techs from the Bluetooth SIG - I'm sure they would be very interested in having your project be a case study. BT Mesh is only 6 months old or so, so there wont be too many people doing what you're doing.

    Sounds like you've considered most of the parameters. A couple more:

    • It's going to get really noisy where device density is high. Consider a scheme that disables relaying for nodes that have a lot of neighbours - if you keep the relaying nodes down so you have just enough mesh paths, you'll avoid it turning into a shouting match where no one gets heard.
    • All relaying nodes need to listen all the time - your relaying nodes wont last long on battery. Make sure you have a continuous power source available for them.
    • The network can be segmented into "groups". But it's really just a logical layer - every node still participates in the mesh (see the dot point about limiting the number of relaying nodes), but some also take action if they're within the "group".

    There's probably not many BT Mesh projects of similar scale to refer to. You could consider widening your search to include Zigbee case studies - mesh has been run and done and cursed and succeeded with Zigbee for a lot longer. Generally the need to continuously power the relaying nodes kills most use cases for mesh, but there'll be some exceptions out there.

    Otherwise you'd really benefit from seeking out some Bluetooth experts, rather than general IoT experts. Start with the SIG and see who you can find from there.

  3. Yes, it is so often the case that the benefit of a capital purchase is not the presence of capital itself, but the impact of that capital if properly managed. In those cases it doesn't make sense for a customer to purchase something they have no relationship with. BMS customers don't want thermometers, they want efficient climate control. Smart Parking customers don't want an array of sensors, they want data. Farmers don't want to manage ultrasound sensors, they just want to know if their tank has run dry. If you sell a widget, then you're incentivised to sell more widgets, even if that's a non-optimal way to solve the problem. But if you sell a service then you're incentivised to make that as effective as possible.

     

    But it does require a bit of future thought from both the customer and the supplier - at least with a capex the customer can say I'm willing to risk $x dollars, hope to break even in y years and after that is a bonus. Where as deciding to sign up for a service means you have a future risk of that service degrading or increasing in price or requiring on-going negotiation. Similarly for the supplier - selling at a margin means you can start at one and grow from there. Selling a service means taking a hit on the first few years until (hopefully) the economies of scale start to work in your favour.

     

    I'm starting to think that given the onus on the supplier to maintain service levels, provide updates and continually chase the security rabbit, that offering a service scheme is the only responsible thing to do. And that building in succession clauses that protect the customer from unforeseen changes will begin to be expected.

     

    So my question is, how long are you willing to bankroll the customer's purchase to provide a competitive upfront price? And what is your incentive to stick with a non-proprietary solution?

  4. Newcastle IoT Pioneers is a free, rapidly growing meetup group established way back in 2016, for anyone operating in the Greater Newcastle region looking to derive some value from the Internet of Things. We meet monthly and last year we had a full calendar of presentations from the likes of Meshed, Thinxtra, Newcastle City Council and Schneider Electric, as well as IoT superstars Stuart Waite and David Goad.

    Today I'm putting the call out early to try to book in some presenters for the year's events. I know there's interesting stories from the trenches to be told but I don't know how to find them! If you or someone you know would like to share your experiences with a friendly bunch of movers and shakers in Newcastle, please get in touch.

    We meet on the first Thursday of every month at a pub in Newcastle.

     

    Regards,

    Heath Raftery

     

  5. Yes, Newcastle only at the moment. But now that we've run our first session the feedback has been very encouraging - we now have plans for expansion!

    Definitely supply and demand is a factor. Like all these trends the supply tends to overshoot the demand. But I think there's also a element of thin value. By which I mean the dominant marketing message is that coding = skill for the future and that code camps = coding competence. When you sell something predicated on those two shaky equivalences you only have a short period of time before people notice the emperor is wearing no clothes.

    So yes, experience with Scratch, using a screen to create rather than consume are very valuable. But I think you also need to get kids off computers and working with things and people. They're the human skills that will always be in demand, particularly in tech and engineering.

    I like your progression idea. I suppose the teachers would argue: sounds great, what are you going to give up to make room for it?

    I was on a webinar this morning with Jon Samuelson on this topic and it's amazing how often he aligned with these themes. For instance:

    • Advice from game developers: don't worry about making things too hard. Kids disengage from school because it's too easy, not because it's too hard. The challenge is the attractive part.
    • "Coding in isolation without connection to physical environment can be just game creation". He goes on to say boys will often go on for days into their own world creating games and learning nothing, while girls will get bored.
    • "Structured play" is the best learning environment.
    • A 21st century learner should strive to: create, empathise, persevere, communicate, envision, be patient, observe, explore, adapt, collaborate, etc. That is, human skills.

    For reference, the webinar url is: http://home.edweb.net/webinar/stem20171011/ and I've attached a couple of his slides.

    Those price points are interesting. We went with $159 for two days and $149 for five after school sessions, which seems pretty attractive. Main challenge is that we want to keep teacher:student ratio really high to provide great service so it's a balancing act.

    As a 21st century learner.png

    Screen Shot 2017-10-12 at 10.28.47 am.png

  6. Interesting. Because I have to remind myself every time, a quick reference for others:

    • LTE Cat-1        10Mbps/5Mbps, full duplex, available Feb 2016
    • LTE Cat-M1     1Mbps/1Mbps, half duplex, available today?
    • LTE Cat-NB 1  20kbps/60kbps, half duplex, who knows?

    All being LTE technologies, coverage should be similar to LTE, maybe even a bit better due to lower rates.

    FWIW, I'm participating in the Everything IoT HackLAB in a couple of weeks. Happens to be hosted at Muru-D in Sydney, and Telstra just announced they'll be bring provisioned Cat-1 dev kits.

  7. Heh, funny you should say that Tim. Cuts to the core of the motivation behind MiniSparx. The programming industry has been very successful in monopolising the mindshare of the tech/innovation industry. Definitely an important part, but I'm not convinced the world really needs that many people proficient in moving sprites in Scratch.

    You might get a rise out of my LinkedIn post:

    https://www.linkedin.com/feed/update/urn:li:activity:6307121692179333120

    FWIW, we'll be using the littleBits STEAM kits.

  8. That's terrific, thanks for sharing.

     

    I ran a community "What's a Smart City?" workshop a while back and put together a similar IoT style, sensor to dashboard kit for participants to experiment with. It was Grove/Arduino/Ubidots based, which proved to be a nice trade-off between simplicity and flexibility. But when I want to "get the point across" on the data collection/marshalling side of things, a Pi running NodeRED is my go to.

    There's a local mob here that do a STEM course called StarLAB. Currently in about 50 schools. Very similar approach to teaching Python in this case - there's a highly integrated sensor module and some of the first exercises are to get the sensor graphs appearing on a computer. The module can even be inserted in a custom rover body and of course, it's not long before students are driving it around wirelessly.

    I also have a STEM holiday program coming up called MiniSparx. It's targeted at younger Year 3 - Year 6 students, so I'm leaning towards more immediate gratification platforms like Sphero and Ozobot, but you've got me thinking about whether there's an IoT angle with merit too.

  9. Love it. All the idle cash in the world is desperate to not miss out on the next Airbnb, and has done a sensational job of monopolising the narrative of business success. Rocket speed growth, a trail of destruction, laptops in cafeterias, and more talking than doing.

    Let the trends be trends. There's no replacement for authenticity.

    • Thanks 1
  10. At one point I swore myself off any engineering project that involved (1) wireless comms, (2) self-sufficient battery power or (3) sleeping microcontrollers. Some how I chose to launch a business right in the triple point that is IoT sensors. After losing a day today dealing with a maddening signal strength issue that popped up out of nowhere, I remember why I made that declaration!

  11. This is a terrific story. I hope you're planning to publish wider (perhaps somewhere on LinkedIn?).

    The story stands on its own two feet, but I'm especially drawn having marvelled at the Plexus/Green Brain system when trying to find an opening for my startup business. We went 80% the way towards developing a remote compost pile temperature monitor with many aspects in common with Plexus, but ultimately the project didn't go ahead.

    The path we have taken, that of Smart Parking, went live on Friday and your story rings home. We set out with a very simple goal - count cars as they enter and leave a car park facility to determine the total occupancy level. What we ended up with starts with a pneumatic system with road anchors, rubber tension properties and a tuned pressure threshold. It passes through an analog electrical interface to a sleeping PIC microcontroller with very tight operating limits for maximum battery life. Then it's into the RF world of LoRaWAN with carefully mapped RSSI patterns as well as robust packet redundancy and reconstruction. The data starts as bytes from an ADC and gets wrapped into JSON for processing and distribution in the NodeJS environment, Node-RED. It splits and goes via MQTT to an IoT cloud backend where it is further processed in Go to produce the raw data for consumption via a couple of different HTML webapps. The other channel converts to CSV and goes via TCP to logstash to populate the NoSQL database1 Elasticsearch for searching and graphing with Kibana.

    Sometimes I stop and wonder if anyone realises what world we've managed to build for ourselves. Perhaps it's inevitable - the customer wants simple and powerful, so behind the scenes an army of engineers from all disciplines build their world ever more powerful and compatible. Before you know it, every little "app" requires the coordination of the latest and greatest from mechanical, industrial, embedded, electrical, telecomms, software and UX engineers. And that's before you even manage to define a product that matches a market, or has great distribution, sales and support.

     

    1. Yes, calling Elasticsearch a NoSQL database is a gross simplification. So be it.

  12. On 01/12/2016 at 1:43 PM, Andrew at MEA said:

    That’s just how it is.

    So very true. But your willingness to share makes a huge difference.

    Many times we have developed a product to meet the expectations set by OEM marketing, using the information provided by the datasheets, with hard won expertise from decades of training, only to discover that we're the guinea pigs finding that the practical limitations fall short of the potential.

    As much as I love to jump on board the next great thing and develop on the latest technology, I've learnt to stay wary of anything that doesn't have a "community" around it. The power of the community is extraordinary, and it explains (in a self-fulfilling kind of way) the success of the Arduino over the STM32 Discovery, the Raspberry Pi over the VoCore, Linux over BSD. It's natural to dismiss these projects as "hobbyist" (and I do, sometimes) but the fact is it is just too time consuming and risky to discover the limitations on your lonesome, no matter how clever and professional you are. You either become the pioneer, investing months and significant dollars to find you've designed your way into a dead-end and the competition is about to leap-frog you, or you navigate the community forums and figure out the capabilities and gotchas from the collective power of the "hobbyists".

    Fortunately by the time I began my ZigBee journey, the community had caught up, and I was able to do my research and set my expectations without much investment.

    On the LPWAN front, of great interest to many IoT practitioners, I've had a foot in both camps. I started by waiting and watching for the community to form, to learn from the scouts at the coalface, suffering the early blows. But I've also discovered that given the focus on European and US markets, and the fact that the Australian market actually has unique technical challenges, that there's value in taking some lead in developing that community. I recently learnt I'm only one of 4 people in Australia with a functioning, Australian regulation compliant, LoRaWAN network made up of components from more than one vendor. Those painful steps into the unknown command a valuable, if fleeting, position in the marketplace.

  13. 3 hours ago, Andrew at MEA said:

    The problem with mesh-networks is the need to keep the repeater nodes (‘routers’) always powered on. This is simply not practicable on a solar-battery budget, unless you don’t mind a big chunky solar panel and fat awkward battery in the mix.

     

    That's the kicker for me - I worked for a long time on applications for mesh networks, and it was this gotcha that killed it. ZigBee (and the 6LoWPAN family) promised so much and battery-powered (periodic sleeping) mesh repeaters is actually part of the ZigBee spec. Turns out no manufacturer supports it because the practicalities of synchronising sleeping nodes in a reliable way to perform mesh networking without compromising energy consumption is just not feasible.

    For now, mesh is relegated to academic projects. If each node contributing to the mesh has to be powered/always on anyway, then you may as well go with a more traditional star network.

    Which is one reason I find LPWANs so exciting - finally there is a low power, low complexity, wireless comms solution for relatively dumb and sleepy nodes. While we wait for national rollouts, we're installing our own LoRaWAN networks to get the job done. I literally just commissioned one last week, so while it is seriously bleeding edge, with all the inherent cuts and bruises, it's into the realm of here and now.

×
×
  • Create New...