I am looking to know the consumption of the TTIG.
I heard about 2-3W. Here@Jeff-UK measure for 24h and I can read 5V/0.270A => 1.3W which is really nothing. I am surprise.
Someone has done deeper test about the TTIG consumption?
Thanks
What method would you be using to power the TTIG? The mains power supply that is build in? Or the USB port?
It helps if you explain why you need the power consumption, that allows us understand how we need to interpret the question. For instance, do you care about peak consumption? Or just an average?
I am going to power it with the USB port.
Where is located the gateway, there is no power. Then I need to use a solar battery with solar panel. Actually, I am using the TTOG but it consum about 7-8W.
As apprently, the TTIG is consuming 2-3W, it’s very interresting. But I do not know how much the TTIG consum as the is no datasheet.
Someone measure 2-3W, apparently @Jeff-UK measure 5x0.270=1.3W. Then I wondering if someone spent time to monitor deeply the TTIG consumption, as I can not find datasheet or spec for the TTIG gateway.
You can look up the consumption of the Semtech chip that forms the heart of a gateway; the ESP8266 has relatively modest consumption in comparison, which is why this comes in lighter than something with a Raspberry Pi or similar. Also presumably it’s using a switching regulator and not a linear one as many simpler designs.
There’s a chance you’ll get this to work, but my strong recommendation would be to pair an open gateway design with a low power CPU. The stuff from pycom seems interesting now that they’ve released their source code.
Becareful what you are reading/assuming! What I posted was the consumption over time which is what you should be considering. I also think you need to oversize to allow for if there is increased LoRa traffic (more/lots of active nodes near by) etc.
The reading you call out is a specific point in time and will reflect if the device is quite idle or not. If there are lots of nodes making join requests or asking for confirmed packets the GW will Tx more often and the spikes will be higher as will overall consumption over time. In addition more active nodes (TX or Rx) will also imply more activity on the WiFi side hence higher consumption there. The peak currents (not accurately reflected/measured by the device shown c/w say using a 'scope to monitor across a resistor) can be significantly higher so the 1.3W you call out from the snapshot measurements is only around half of the actual average in a general test hence the call out of a 24hr consumption.
I’m not actually sure that’s true; the transmit path consumes well less than the receive path, though I guess the receive isn’t actually suspended as in some configurations you can receive your own transmission (if you command one with compatible air settings, for example for gateway-gateway ping studies)
But in a time average, transmit is really nothing compared to the heavy DSP of the multi-channel/multi-SF receiver.
The time average point is true but what I am am calling out is the simple assumption of 1.3W being a vaild indicator - those 3 pictures were just snapshots during a quiescent point (I wasnt trying to cature those - only highlighting the total mAH consumption over time indicated by the USB monitoring device (the accuracy of which I would not take as gospel ). The pictures were taken just as I saw the time roll over for 17, 20 & 24Hrs respectively vs looking to take during a reported current spike. As @bertrik also identified there are higher spikes ( I recall seeing around 0.35/0/37A and even a few at 0.45+A) when watching at various times), note also these were early days with the TTIG - havent done any recent checks with latest firmware or backend changes wrt keep alive on the Web Sockets interface etc. - I must remember to re-check sometime
Another point when sizing battery is that of battery fatigue. A constant drain at say 0.25A will yield one discharge curve/capacity however, start hitting with spikes of consumption 100mA, 200mA or more higher and, depending on capacity, battery chemistry/construction and efficiency of any power management circuit around the battery, you will see the real world delivered capacity can be quite a bit lower.
Thanks a lot for your interesting feedback and thank to @bertrik for doing that interrestiong test.
The reading you call out is a specific point in time and will reflect if the device is quite idle or not
Yes I am aware.
I did the same test with the TTOG and I observed about 6-8W.
It’s look like TTIG consum twice less even more, and that’s very interesting
My TTOG run about 10 days without sun with a 120Ah solar battery and 180W of solar panel.
If now I use a TTIG with a 120Ah solar battery and a Netgear 4G model (power with his own batery, MPPT and solar panel), I can hope (and estimate), the TTIG will work more than 20 days with a very bad weather.
As I already have all the materiel, it’s interesting to buy only the TTIG for 90 Euro and test it
but my strong recommendation would be to pair an open gateway design with a low power CPU
No, a gateway consisting of a concentrator card and a low power computer and a standard SPI interface in between, such that you can customize all of the details, rather than the take-it-or-leave-it fixed function TTIG.
I’d pretty seriously look at the pycom offering where you socket one of their ESP32 modules into the radio board. I’m not sure I’d end up using it exactly as it, but it seems like a good starting point for customization.
Something you’ll probably also want in a battery powered setup is some self-reporting; are you going to have the gateway’s processor do that, or do you want to add something else, like a captive node to read the system battery and transmit to the gateway using a 50 ohm resistor instead of an antenna, in order to not cause overload problems? That’s certainly possible if you want to go down that route…
Getting rid of the wifi in the middle seems like a big win in terms of reliability, and can’t hurt the power situation either.
I just plugged my pygate/wipy gateway behind an UM34C USB meter.
As first comparison after initialisation of the pygate concentrator current jumped from 0,09 A to 0,4 A at 5,27V
I leave it running for approximatly 24h an will report the count of tranmitted and received packets for comparison.
I leave it running for approximatly 24h an will report the count of tranmitted and received packets for comparison.
@engelking, That’s great, thank. Yes keep me posted.
I’d pretty seriously look at the pycom offering
That’s interesting for sure, but to be honest, I do not know if I would have time to learn about a new devise. I have been using pycom product some year ago and I have two lopy4 boards, and extension board at my place. Is it easly and fast to setup a gateway with Pygate, keeping in mind I have no expertise with that devise?
In any case, I will need the 4G Netgear AC 675 router
No time like the present - have kicked off an overnight test, running for 50 mins so far consumption is 300mAh off 5.12v (started at 4.97V but also now charging a USB Powerbank/Battery off same USB Power Adapter overnight and it compensated for the near 2A charging current by increasing the USB voltage )
I watched the readings a few times and typically running at 0.35A or 0.38A with lowest seen an occasional 0.32A and peaks of 0.41A. Will leave running for 12 hrs and report back tomorrow on observed consumption…
I did the setup without prior knowledge of the pycom ecosystem.
The result was a stabel working but very basic Gateway with an even smaler size than the TTIG.
Perhaps there is some room for energy optimisation. For example in my setup the rgb led is constantly on and the green light has a significant brightness.
Propaply it is possibel to use a Gpy instead the WiPy and use the LTE CAT-M as network uplink.
As long as i am totaly unfamiliar with LTE CAT-M this is a simple assumption.
Hi Tony HNY2U
The OP above has link to original post (where I also mention experience with Pi/Pi0 builds & e.g. Laird for comparison) - I use basic USB Monitoring sticks, not precise and some variable between builds but a reasonable 1st order view. I got them originally for testing charge and discharge capacity of USB power banks - as I didnt believe the marketing bull/claims on capacity claimed by suppliers) and for simple check on USB voltages when powering GW’s (I can power Laird RG1xx units from USB supplies/Battery banks where at higher end of voltage spec if turn on ramp fast enough to defeat brownout detection, but not if at low end so I select on test those adapters I then know capable of working). My tests were with SX1301 based systems, with the TTIG bringing in the SX1308. Not had chance to do similar with SX1302 systems yet (Had hoped I might have seen one of your ‘Tubes’ by now ! )