Jump to content

Heath

Registered
  • Content Count

    46
  • Joined

  • Last visited

  • Days Won

    29

Posts posted by Heath


  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 heath@newie.ventures 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. Some good points made there. Probably won't surprise any engineers to find that not all screwdrivers fit all screws. But yes, in the hype-driven business decision making world we live in, there are many examples of trying to use a screwdriver to hammer a nail.

    I'd go as far as to say the challenge is not to "figure out ways around these problems", because that assumes the fallacy that, for example, "edge" computing is a novel invention from the cloud era. In reality, processing has always been done at the edge, and cloud computing paradigms simply mean we need a term to describe the adoption of legacy paradigms.

    I'd prefer to frame the challenge as doing our due diligence on the applicability of new tools. If cloud does not provide net benefit, then the solution is not to adopt it. In reality, there are likely to be aspects that can benefit from new technology, and so the challenge is to astutely adopt aspects of new technology that provide net benefit.

    I get a little tired of the one-size fits all hype, that then hyper-hypes accommodations that are simply existing techniques wrapped up in new lingo. You see this a lot, for example, in web development frameworks. Every few years all the problems are re-solved, only to reveal a different set of issues that had already been solved.

    • Like 1

  10. Fascinating. Quite an achievement. This is certainly a promising way to get started building a blockchain based application. Time will tell how effective it is in practice - currently the user base is heavily dominated by those with a vested interest in giving it the thumbs up!

    I'm encouraged by their approach to scalability and confidentiality. These are well known problems in the blockchain that underpins Bitcoin and to some extent Ethereum. Sounds like they've taken a few pages out of the Monero playbook, which I personally think is likely to be the cryptocurrency of choice for discerning traders!

    IOTA seems to have similar goals, though has a different approach to the challenges. To me Fabric feels a bit more professional/cohesive/supported but the proof will be in the pudding.

    In either case, the applicability to IoT is, like most things hanging off the IoT bandwagon, tangential at best. Like any distributed ledger technology, anything that requires a trustworthy exchange of value could potentially benefit. The bog-standard application is financial transactions, but it's not hard to think of more IoT related applications: trading electricity micro generation and consumption; data consumption by device; pay-by-the-listen music; insurance adjustments based on location/activity/etc. But it's those pesky implementation details that will really bring to life just what problems this solution solves.

    I'd love to have a (paid!) project to put this stuff to work on, but alas, I await for vicarious outcomes!

    • Like 1

  11. Did my post get deleted or did I forget to hit the submit button?

    Teksmobile, Hussain Fakhruddin and Romit Kumar are very prolific on LinkedIn on this topic, and I don't think they're doing the industry a favour. Their articles are misleading, confusing and full of errors. This is another example. I'm sick of charlatans confusing the public and making the job of the practitioners even harder. Dealing with a confused public that doesn't know who to trust makes it hard to make progress. Thus, I was motivated to reply. Here it is:

    Quote

     

    Yay, another half-arsed article from Teksmobile on LPWANs to confuse an already confused public. Here we go again:

    • 01. You're conflating three things here: the distinction between LoRa and LoRaWAN; NB-IoT's (lack of) standardisation; and the distinction between cellular and non-cellular comms. They're not related.
    • 02. Channel bandwidth is a technical detail utterly irrelevant here, unless you care to explain the pros and cons of spread spectrum and ultra-narrowband. It's not possible to make an assessment on the information provided.
    • 03. Both technologies require gateways. NB-IoT calls them "base stations". LoRaWAN calls them "gateways". They're both star networks, they both need them. Someone has to manage them in both cases. Perhaps the distinction you're trying to make is that with LoRaWAN you have the option of managing your own. With NB-IoT, only licensed carriers can operate them. You make this point in #07.
    • 04. Battery performance is not related to frequency band. Otherwise, yes, this point is correct! Not useful, but correct!
    • 05. No, LoRa is not "the IoT network standard" in any of those countries. It's just very popular in those countries.
    • 06 & 07 Yes! Nice one.
    • 08. You're conflating signal propagation distance with network coverage. Propagation distance really comes down to the Maximum Coupling Loss (MCL). LoRa is about 165dB and NB-IoT about 151dB, with a bunch of caveats on both those figures. In theory that means LoRa can transmit twice as far as NB-IoT, but practice doesn't care much about theory and there are so many caveats it's not worth comparing. Network coverage on the other hand, is all about the location of the base stations. In that case, yes, NB-IoT's coverage is likely to be similar to 4G coverage, while LoRa can be anywhere. The LoRaWAN gateways still need an Internet backhaul service though, so unless you have a cabled Internet connection handy, you might still be relying on cellular or WiFi.
    • 09. The overall point is correct, but all the technical details are wrong. Looks like you've tried to paraphrase the LoRa Alliance's whitepaper on this topic and made a meal of it. There are no "asynchronous bands", no "peak current orders" and no "non-linear modulations". The words you've copied from the whitepaper are right, they're just not put together in the right order and are now nonsense.
    • 10. Yep.
    • 11. While NB-IoT is not yet working "like a charm in the public domain", the rest is fairly accurate.
    • 12. Yeah, this is a complicated one. It can't be answered by quoting dollar figures on module cost - these bandied around figures are quite misleading. It also doesn't help to conflate the operator's costs with the user's costs. You really need to consider a couple of use cases and compare apples with apples.

    Hussain you're a very prolific contributor to this topic. I hope you appreciate the influence you have on a public that are trying to make decisions based on sketchy data. Spreading misinformation does the industry a disservice.

     

     

    • Like 1

  12. I'm interested to see the responses to this. I know the IoTAA is busy assembling a "maturity index" which has as one of its aims the compilation of organisations that have achieved some business sustainability via IoT products. It would be a great source of the stats you seek but I think it's still a work in progress. There's about 180 of us in the "startups" worksteam (WS6) so there's plenty vying for some traction.

    There's a scattering of good news stories getting about but I'm not aware of a list yet...


  13. 18 hours ago, Tim Kannegieter said:

    The example of failures above misses an important fact about machine learning is that such systems are trained. yes they may get it wrong but over time they get better and better, and are usually more accurate than humans in the end. Also, such machines will improve over time.

     

    I don't know where people keep getting that notion. I suspect it is fuelled by works of science fiction. Machine learning does not keep getting better with more training. It reaches a point where it starts to either specialise (ie. it has learned the training set so well that it can no longer generalise) or the accuracy hits an asymptote (ie. there is no better hyperplane that divides the input vector), at which point it is over trained. Getting machine learning right is about ensuring you implement the right stopping conditions. And the machine learning referenced by Jeff Clune in the article I rerferenced is the state of the art - they've been trained as best as the best ML practitioners can manage, and they're easily fooled. ML can also never be "more accurate than humans" - accuracy requires supervised learning and supervised learning requires humans to provide the classifications for the ML to learn from. So humans must set the bar for accuracy which the ML attempts to meet.

    The whole profession will get better certainly, but in the 30 or so years that ML has been under serious development, we've gone from being able to recognise objects in images to being able to do it faster (and market it better!). There's some fundamental challenges. ML is and always has been, an excellent tool. There's no evidence so far that it will lead to some kind of general intelligence with no bounds.

     

    Quote

    I liked this example of cognitive computing where I think super sensors could be used.

     

    Yeah, loved that one too! But that was the opposite of a super sensor right? They're suggesting that instead of having one wrist worn sensor to rule them all, you litter specialised sensors about the place to build up a image based on lots of different inputs.


  14. I really did get inspired when read the two original stories. But as usual in this field, I think imagination is getting well ahead of reality. The "as it gets better" argument really doesn't hold much water when you're talking about a system that provides diminishing returns.

    I love the potential of image recognition. But it's just one coarse view on the world. It's foiled by shadows, darkness, occlusion, contrast, reflections and so on. AI-based image recognition learns patterns that can often be so at odds with the way we understand vision to be useful, that it fails in specularly bizarre and unpredictable ways (eg. https://www.wired.com/2015/01/simple-pictures-state-art-ai-still-cant-recognize/ amongst others).

    And I really got carried away thinking about the implications of the super-sensor. But again, it's a coarse view on the world.

    In both cases they are amazing examples of what can be done with less. The potential for parlour tricks is endless, and there's even lots of practical applications. But I don't buy the evolutionary conclusion - both approaches are coarser abstractions of the sensed variables. Coarser abstractions give you a wider view (you can detect more things), but they can never add information. Information is lost in every abstraction that cannot be recovered. There will always be cases where a direct sense method is the only way to achieve specificity, accuracy or noise-immunity.

    Technically I can hear every conversation I'll ever need to hear without leaving my office - I just need to amplify the vibrations of my desk. In practice I'm better off picking up the phone.


  15. But can it run Crysis?

     

    Seriously, these are fascinating. The mind just boggles at the implications. There'll be some niches where the size is a gamechanger (inside the body, "smart dust", etc.), but for many practical purposes the size might be a hindrance. The power requirements though - potentially indefinite battery life in indoor lighting - raises some interesting prospects.


  16. Good points. The power, as it so often does, comes from combining data sources. Tyre pressure with fuel consumption by route - what is optimal? Tyre temperature with pressure, ambient temperature, vehicle speed and driver identity - who's smoking the tyres? Shock events, location on vehicle and vehicle position, aggregated over many vehicles - pothole detector!

     

    But Jason's point is a good one - sometimes you just need to start instrumenting and discover the insights later. I'll give you a recent example - the instrumented pneumatic tube vehicle counters we developed for our Smart Parking system report on various parameters that aren't critical to the core product. One started to fail recently in a way we hadn't seen before. Turns out one of the tubes had lost its springiness. But thanks to our collected data, we now have a unique data signature that alerts us to a pending "springiness" failure! We can even see the clear progression from healthy to point of failure, and combined with traffic counts and ambient temperature records, we can predict time to failure. That's really quite powerful, yet we never imagined it when we were designing it.

     

    Last thought... how do they measure vertical load from within the tyre? Maybe it's based on internal tyre height at the bottom of the tyre vs at the top to get a measure of deformation, combined with the tyre pressure to get total load on the rubber? I can't see that being particularly accurate!

    • Like 2

  17. On 14/03/2017 at 2:15 PM, Tim Kannegieter said:

    ...there is a parallel maturity of individual organisations, industries and society in general that needs to occur. 

    That's it - it almost doesn't matter how mature one's technology or technical capability is if it is not well aligned with purchasing expectations.

     

    On the density matter, I had in mind a way to measure the sophistication of installations - there's plenty of connected things already, but the great promise of the IoT is that it can be done at significant scale do to technology advancement. So if your garage door talks to your car, that's M2M, but if light switch in the house is remotely monitored, then that's further along the IoT path. Coarse, I know.


  18. There was some discussion about defining maturity at the last meeting of IoTAA Work Stream 6 (Startups). While this example wasn't mentioned, there was a general acknowledgement that it's a difficult task. I'm pleased there also tends to be a general understanding that there is a chicken-and-egg challenge in that the IoT market is quite immature, so proudly claiming one's own maturity is misleading at best. I think you're getting at the same thing - until customers are informed enough to write confident purchase orders, any one claiming a level of maturity is just waving their peacock feathers.

    With so much still subject to debate, perhaps a framework with more quantifiable aspects might be attractive: dollars saved via the IoT; regions covered by LPWANs; density of things; hours of uptime; number of IoT startups; percentage of active participants in an IoT association. But you might be on to something - while there might be a heap of technical capability ready to come online, the IoT can't be considered mature unless people are actually paying for Smart Parking installations, or autonomous farming equipment, or Smart meters or whatever.

    • Like 1
×
×
  • Create New...