Nick

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • in reply to: IP67 Geolocation Conduit – AEP Available? #28647
    Nick
    Participant

    Nice! Thank you and I will give a go.

    Nick

    in reply to: Power Draw of the IP67 Conduit #28232
    Nick
    Participant

    I had no luck and no input from M-T and I never had the gall to crack mine open. Might seem odd, but I have a “spare” that I can operate on, but I have no time. If you are near Milwaukee, I’d consider letting you tinker with it.

    What we did initially was buy a DC-to-POE converter and put it in our battery bank to power the unit. This was killing our solar power. So we tried plan B.

    Plan B include a standard Conduit with a good enclosure. It is much easier to buy the standard Conduit and a good, locking, IP rated enclosure to mount it in. We punch the holes and added the bulk-head connectors for the antennas, power, etc. We used internal antennas for the wireless since we weren’t concerned about wifi signal strength. We did not add any vents…I was concerned about heat and moisture, but so far, so good. We put some desiccant in the enclosure to try to suck up as much moisture as possible. I should note the solar charge controller is in a separate battery box – the charge controllers tend to create a lot more heat. Molex makes tons of slick vents that we will utilize in the future. Gore makes good vents, but they require a lot more input on their end before they will sell them.

    For charge controllers, we used a very small output, very low cost unit. One feature I recommend is that the charge controller automatically cuts power to the unit if the voltage drops below a certain threshold and only comes back on once the voltage rises above the cut-off plus a delta voltage. If this is not done and the Conduit is powered from the batteries, you flirt with a low voltage situation where the Conduit repeatedly tries to start up – say a few hundred times an hour. Can’t be good for anything and don’t ask me why I know this. Let’s just say the IP Conduit’s power supply requirement put through a lot of headaches.

    The biggest benefit of doing all this is that it can significantly reduce lead time. We had some longer lead times on the IP Conduit flavors, but the regular Conduits are commonly stocked. Cost wise, I think it can save a bit, but not much. I think we could have saved more if we had planned it better. I’d really have to sit down and see what we save on DC-to-POE injectors, additional solar panels, etc. to see how costs flushed out. Bottom line is that it saved our solar bank and power has been right where we need it too be and haven’t had a problem since.

    in reply to: FUOTA – ?'s, Details, and Use #27189
    Nick
    Participant

    Roger that. Thanks.

    in reply to: FUOTA – ?'s, Details, and Use #27187
    Nick
    Participant

    Maybe a dumb question, but it possible to execute a FUOTA from MT DeviceHQ? Or would we have to be connected directly to the gateway to execute?

    in reply to: Conduit IP67 – mLinux and AEP #26760
    Nick
    Participant

    Will do. Thanks for the reply!

    in reply to: Firmware Update 1.6.2 – No Connections #26715
    Nick
    Participant

    Yes, I connected the Conduit via wireless and it came up. I am not sure why the connection via the LAN port did not work. It was working well hardwired to our network prior to the update. When I get time, I will try to diagnose the issue and report back.

    in reply to: Firmware Update 1.6.2 – No Connections #26713
    Nick
    Participant

    ******** UPDATE ********

    I connected it to a wireless network and it’s working fine now. Something must have happened to the LAN connection with the firmware upgrade.

    I do need this connected via the LAN port, so if anyone has any ideas…

    in reply to: FUOTA – ?'s, Details, and Use #26601
    Nick
    Participant

    The link that Ryan posted above contains a lot of information regarding a required update for Conduit. When I read through the information on the link, it appeared to be pretty complete. I only had a handful of questions that I figured I could work out when I gave it a run through. Unfortunately, I have gotten bogged down on another project and I haven’t tried it yet, though it is on my list of things to complete before the end of October. I was also in the middle of development and didn’t want to update any software on my devices for fear of breaking anything software wise.

    When I get through it, I can post some info regarding my experience. I will try to make a list of things that I saw as “holes” in M-T’s literature.

    Sorry I can’t be of more help at the moment.

    in reply to: FUOTA – ?'s, Details, and Use #26362
    Nick
    Participant

    Awesome! I’ll have to dive in and figure out how to do it. This ability will be very useful.

    in reply to: LoRa and Telit deviceWise #26225
    Nick
    Participant

    Figured I would post a follow up to my own post. I got some info and found a solution.

    In talking with Telit, they are set up to use a LoRa service provider, but don’t really have an option for our own LoRaWAN (Conduit with LoRa mCard). There are a few things that can be done to send messages to the LoRa edge devices.

    1. Set up a method and utilize Telit’s workbench software to process the method message and re-broadcast an MQTT message. I believe this creates an extra loop back to the platform (additional API calls can lead to additional charges).

    or (and the way I am handling)

    2. Use the alarms to set parameters – the parameters might seem limited, but some additional data can be sent in a “message” that go along with the alarm state change. I use Node-Red to listen in on the MQTT alarm state change topic. When the alarm state is changed, the MQTT node (in the Node-Red flow) picks up that data which I can then process and send via LoRa. Works pretty slick, though its likely not the intent of the alarms.

    in reply to: mDot Box – Sending Data Through LoRa #25675
    Nick
    Participant

    Just and update to this. I tried a few experiments to crack this one. One of the easiest methods I found was to utilize a union to create a byte-array to send via LoRa. On the other end (MT Conduit LoRa Gateway) I had to do some bit shifting into a new array (in JavaScript) to get back to the true integer value.

    On a side note, I sent the Analog.Read value as the uint_16 value via LoRa since it was easier than translating the float value in Node-RED. It’s quite simple math to convert the analog value to our true measurement value, but I figured performing the math at the Conduit (not battery powered) would be fundamentally correct since we want to conserve as much power on the mDot as possible (though probably not much).

    in reply to: mDot DHT & RH Example #25631
    Nick
    Participant

    Yep, that was it. Took me a good while to figure it out. I thought I was being smart by updating the libraries…I ended up removing it from my library and re-importing.

    in reply to: Can't Connect mDot Box to Conduit After Reset #23990
    Nick
    Participant

    Awesome. Thanks!

    in reply to: Can't Connect mDot Box to Conduit After Reset #23988
    Nick
    Participant

    UPDATE

    I got the mDOT Box to connect. I set the Network Mode to ‘Private MTS’. Under LoRaWAN Networking>LoRaWAN Network Server Configuration>Network.

    What is the difference between LoRaWAN and MTS?

    Thanks!

    in reply to: Can't Connect mDot Box to Conduit After Reset #23977
    Nick
    Participant

    I would have to double check; I am out of office, but I can stop in and check. I know it was under the LoraWAN settings. I believe it is the page that has a button to hide/show more advanced options. I can take some screen shots or figure out a way to output the info in text friendly format.

    I did change between public and private Lora network and gave it a try, but it still didn’t work. On a side note, it is set to network server mode.

    One thing I though about on my way home yesterday…I was going to try to change the Network Name. I was unsure if the mDot Box possibly contains a setting that needs to be refreshed/forgotten (similar to how SSH terminal connections can throw a warning after resets).

    When I view the Lora network activity I can definitely see the mDot Box’s attempt to connect.

    Thanks,

    Nick

Viewing 15 posts - 1 through 15 (of 15 total)