Battery Library For Proteus

[Casimiro Lurten]

HelloGuys, In this post, I will share my new Battery library for proteus professional. This Battery library for proteus can be used with any kind of circuit simulation where DC Supply is required. This Battery library is compatible with all versions of proteus as well as stable for any environment.

i have a project name is High-Efficiency 3A Battery Chargers Use LM2576 Regulators. and i am doing my simulation in multisim and proteus but my whole simulation project is useless without lm2576 regutor.How can i find lm2576 library in multisim or proteus please help me. i am really desparate.if i cant find this library can i create my own component lm2576. how can i create this component or can i find this component in libraries for ready to use

The setup for my field application is a MKR WiFi 1010 stacked with the MKR GPS shield, the MKR ENV Shield (version1), and 2 analog sensors, with data saved to a microSD card onboard the ENV sensor and GPS data transmitted over BLE to a phone app (this was done to try to keep an eye on the GPS connection in real time).

This field application runs on battery power, so uses no serial commuincation with the laptop (i.e. no Serial Monitor). This code has run for long periods of time, collecting hours worth of data on the SD card... but this is not EVERY time. In fact, it's only about half. Other times, I use the same sketch and check the SD card to find that only the headers have printed and no data was saved. I've explored forums and taken the suggestions of removing delays and editing the library (MKR GPS Shield Sampling Frequency) but to no avail.

Now, I have gone entirely back to basics and am still left puzzled. I am using the GPSLocation example sketch that comes with the Arduino_MKRGPS library (only edit is the line that initializes the GPS in shield mode, GPS_MODE_SHIELD).

There are no delays in this sketch, and of course I have the SM open on the correct baud rate. It is supposed to just continuously print 5 parameters to the SM. I have run this sketch repeatedly in the same, unobstructed location over the last few days and this is what has happened:

I have made my way into the CPP files of GPS, minmea, and SerialDDC and right now it is beyond my current programming abilities / comprehension. I will be doing some reading to understand NMEA and parsing and how the data being received by the GPS actually gets printed to the SM.

Being that time is a very precious resource and this problem is currently holding up field work for my dissertation, I am hoping you kind people may be able to help me narrow down my issue.Just getting the GPS to print at a consistent rate to the SM is step 1. Then I can get to figuring out if this fixes my problem in my field application.

I wish I had a logic analyzer but I do not. I will, however, be putting together a test suite where the Arduino and Photon will talk over Serial connection in an attempt to be able to do this analysis.

@rkast4321, looking at the library for this device, I believe it should work as-is with the Photon. The choice of hardware or software serial is done in the user code. I suggest you use the hardware serial Serial1 port (TX/RX pins) on the Photon and refer to the hardware serial examples in the library.

I went through a variety of different power sources. Bench power supply for both, usb for the photon, and eventually to a 5v/2amp capable barrel-jack style power supply. So I suspect as long as both devices have their power light on then your solution will work.

I want to power SRTR via Boron 3.3v pin but I guess the current draw on the SRTR is way too much for the Boron 3.3V pin to handle. I used RFP30N06LE MOSFET and Pololu 5V Step-Up Voltage Regulator U3V12F5 to try out but was not able to power SRTR successfully.

OK - you need to read the data sheets - this device can consume up to 1.1A - the Boron device CANNOT provide this level of power. At best you will have to connect the SRTR to the VUSB and supply it with 5V. You will then need to use a level shifter to reduce the level for connection to the Boron pins. IMHO - this means you will need an external battery pack to power the whole solution and not rely on the boron's LiPo and associated charging circuit.

The voltage regulator on the Boron is rated for 1000mA and the Boron needs a considerable amount of that for itself - only the remaining reserve can be used to power external devices.

Here is the eagle library for the TP4056 Li-Ion battery charger in SOT-8 package. The library was created for my wireless headphones project but the TP4056 is not going to be used. Hope someone finds some use for it.

One of the main differences between them is the computation power which translates to power consumption. And, of course, in the chip cost; a CPU is much more expensive than an MCU. Typical MCU costs ranges from few cents to few dollars. CPU cost is a scale factor of at least 10 or 100.

On the MCU world, there is the possibility to just sleep or go to a deep sleep mode reducing even further the power consumption. You can wonder: what can wake up the MCU? It depends on the MCU. One of the most common situations is based on a timer. Technically speaking, everything will be shut down, except a small watch crystal and a timer. Those elements consume only few micro-Amperes, meaning that the unit can run those on a battery for years or decades. When the time to wake-up is reached, the MCU awakes, performs the boot sequence and it starts executing its program.

There are other ways to awake it, just like in real life! The cold bucket of water or someone shaking you up is as well possible. This one is called an interruption. In the MCU world, it will mean a change of state on a General Purpose Input/Output (GPIO) pin. In short, something happened. You pressed a button, or you touched a screen changing the state of the GPIO. This mode consumes a bit more energy than the previous one, still, the processor is deeply sleeping, and, again, only few micro-Amperes are consumed.

.NET nanoFramework addresses the world of MCU and supports this sleep mechanism for all the supported architectures like ESP32, STM32, NXP and TI. This enables scenarios to have .NET code running for years on a single battery, as I will explain later,

What interests us most of the time in this IoT world is to measure an element from time to time, send this data over the air or a cable and wait for the next period to measure it again. This is the most common scenario in the IoT world. You want to consume as little as possible; you want to change the batteries as infrequently as possible, and you still want the device to say it is alive time to time.

.NET nanoFramework has a Visual Studio Extension that you have to install. You also have to flash your device. Then you can debug your C# code like you do with any .NET application! You can as well connect to a Wi-Fi or a wired network. Helpers make your life easy and everything you need is in a nanoFramework NuGet package. The first part of the code connects to the Wi-Fi, requests or renews an IP address:

The Azure root certificate is needed to validate the identity of the endpoint we are connecting to. It is stored in the code resources. .NET nanoFramework offers a concept of application resources as well.

We are registering for events. Here, we will be interested in the messages that we can receive, and the confirmation that those messages have been received by Azure IoT. There are more events you can subscribe to. This is done in two steps, first one with the MQTT class and second with the protocol.

To connect the device itself, a shared access signature is required. This calculation is made with class helper which allows to create using a HMACSHA256 calculation. Most of the parameters are specific to the MQTT protocol and documented on Azure IoT Hub documentation.

Moving forward we are requesting the device twin for this device. A twin is a concept that is creating desired properties and reported properties. See this as a desired and reported configuration for the device. It is up to you to define what you want to setup.

This sensor has been implemented in .NET IoT and ported to .NET nanoFramework. .NET nanoFramework offers a large library of sensors, based on the same code base. Because .NET nanoFramework has constraints, every binding has been split in each own NuGet. The code for those bindings can be found at the nanoFramework.IoT.Device repository. The code had to be transformed to support the specific project type of .NET nanoFramework and other specificities like transforming generic list or span into non generic ones. Because of the size constraints for example, Enums have a simplified implementation. IsDefined or GetValues are not available because the description of the Enum items is removed to save flash storage in the MCU.

Also, a lot of work and efforts has been made to allow a simple, consistent and straight forward for all the supported bindings. This allows to develop solutions in .NET that are easy to reuse from the code and support perspective on a CPU and on a MCU.

The Sleep class is specific to .NET nanoFramework and was specially designed to manage the sleep modes on every device. Despite having a common API, the low level implementation is specific to each supported MCU. Some offer more features than others. API are aligned and if a mode, like the timer one, is available on all MCUs, the API will be the exact same.

In about 100 lines of .NET code and few hours of effort, you can then connect to a Wi-Fi network, connect to Azure IoT Hub, get the twin properties, report them, measure a sensor, report the measurement to Azure IoT Hub and then enter deep sleep mode, lowering the power consumption of an MCU! The .NET nanoFramework NuGet and existing code helpers make that easy.

So, for this phase and to measure how everything is running, an external logging mechanism can be used. We will use a serial port, plugged on the machine. A tool like Putty or any other serial reader will work perfectly to capture the data.

3a8082e126