Recent Posts

Pages: [1] 2 3 ... 10
1
MoteinoMEGA / Re: Over the air programming corrupted on reset
« Last post by RatTrap on Today at 05:46:35 PM »
I forgot to be clear the Flash LDO is powered from the battery line.  It is only enabled from the mcu.  Perhaps I have a timing issue.  The LDO might take longer to turn on that the time between turning it on and the Bootloader attempting to read the bytes.  Doesn't explain why the bytes are changing during the reset but it is a theory.  One that I will test as soon as I figure out how to add a slight delay to the bootloader.  Modifying the bootloader is way outside my wheel house and I wouldn't attempt it if I didn't have absolutely no other choice.  Do you think that a timing issue may be the problem?
2
MoteinoMEGA / Re: Over the air programming corrupted on reset
« Last post by RatTrap on Today at 01:45:21 PM »
Fair questions I am using the same Windbond 4mbit W25X40CLSNIG that is on the moteino mega.

The separate power system has been a thorn in my side for a while and is being eliminated on the next run but before they will produce the next run they want to make sure that I have the system fully functional. grrrrr :(

in any event each of the peripherals are powered by their own individual LDO regulators and each of those regulators enable pins are connected to a different IO pin on the mcu.  To turn on the peripheral device all one needs to do is to write that pin high.  In the case of the flash and normal programming that is simply
Code: [Select]
pinMode(B0,OUTPUT);
digitalWrite(B0,HIGH);

Turn it off would've been writing it low but putting it to sleep actually uses less power.
Code: [Select]
//digitalWrite(B0,LOW);

flash.sleep();

in the case of the boot loader and I'm not sure I got this correct because I question my understanding
Code: [Select]
MEMON_DDR  |= _BV(MEMON_PIN);
MEMON_PORT |= _BV(MEMON_PIN);
should turn it on at the very beginning of the CheckFlashImage() function in the bootloader.  Or at least that is what I'd like it to do
3
MoteinoMEGA / Re: Over the air programming corrupted on reset
« Last post by Felix on Today at 10:28:44 AM »
Quote
foolishly uses a separate ldo from the mcu to power the flash memory.  That LDO is on Pin B0 and the flashSS is now on B1
Huh? Ldo from MCU pin to power a flash memory chip?   ???
How exactly does that work? That could be the problem.

What flash chip is that? Did you verify it has the same commands used in the bootloader?
4
MoteinoMEGA / Over the air programming corrupted on reset
« Last post by RatTrap on Today at 08:50:34 AM »
So I have a design that is extremely similar to the moteino mega and am using the dual optiboot bootloader to fascilitate over the air programming.  For some reason the bytes written to the flash memory before the reset are changed during reset and programming is not executed. 

Here are the differences in the board and the changes in the bootloader. This prototype moved a few pins around and foolishly uses a separate ldo from the mcu to power the flash memory.  That LDO is on Pin B0 and the flashSS is now on B1.  The changes to the bootloader are as follows

accounting for the new pin to power on the LDO
Code: [Select]
#elif defined (__AVR_ATmega1284P__) || defined (__AVR_ATmega644P__)
  #define FLASHSS_DDR     DDRB
  #define FLASHSS_PORT    PORTB
  #define FLASHSS         PINB1
  #define SS              PINB4
  ////////////////////////////////////////
  #define MEMON_DDR   DDRB
  #define MEMON_PORT   PORTB
  #define MEMON_PIN   PINB0
#endif   


and turning on the LDO
Code: [Select]
void CheckFlashImage() {
#ifdef DEBUG_ON
  putch('F');
#endif
  watchdogConfig(WATCHDOG_OFF);

// POWER ON THE FLASH MEMORY -ADDED BY CHARLIE
MEMON_DDR  |= _BV(MEMON_PIN);
MEMON_PORT |= _BV(MEMON_PIN);
/////////////////////////////////////////////////

The code has been delivered and verified intact and uncorrupted to the device over the air and has been successfully and accurately written to the flash.  After the code is verified I add the FLXIMG:<Size>: to the first 10 address on the flash and issue the reset.  For these test I am triggering the reset manually.  The reset itself is caused by a watch dog time out. 

Here is the code to finish that final part, as I just described
Code: [Select]
flash.writeByte(0,(byte)'F');while(flash.busy());
            flash.writeByte(1,(byte)'L');while(flash.busy());
            flash.writeByte(2,(byte)'X');while(flash.busy());
            flash.writeByte(3,(byte)'I');while(flash.busy());
            flash.writeByte(4,(byte)'M');while(flash.busy());
            flash.writeByte(5,(byte)'G');while(flash.busy());
            flash.writeByte(6,(byte)':');while(flash.busy());
            flash.writeByte(9,(byte)':');while(flash.busy());
            flash.writeByte(7,(ProgramSize>>8));while(flash.busy());
            flash.writeByte(8,(ProgramSize&0xFF));while(flash.busy());
            for(int i=0;i<7;i++){
              Serial.print(char(flash.readByte(i)));
            }
            uint16_t Size=(flash.readByte(7)<<8)|(flash.readByte(8)&0xFF);
            Serial.print(Size);
            Serial.println(char(flash.readByte(9)));
            Serial.println("Press enter to reset");
            Serial.readString();
            while(!Serial.available()){
              wdt_reset();
            }
            delay(30000);

Here is the output from the serial monitor of the device
The first line is the first 10 bytes read from the flash memory cast as their correct data types, which verifies that the code has written correctly.  The second to last line copied is the same bytes read after reset, and for good measure I also printed those same bytes hex values in the final line.
Quote
04:17:38.557 -> FLXIMG:65534:
04:17:38.557 -> Press enter to reset
04:18:04.361 -> ------------------------------------------------------------------
04:18:04.361 -> Starting--------------------------
04:18:04.361 -> Firmware Version: 0x1
04:18:04.361 -> ------------------------------------------------------------------
04:18:09.347 -> SerialNumber: E C A 5
04:18:09.347 -> Report Time is: 16:30
04:18:10.965 -> Turning off Radio
04:18:11.001 -> NetID: 14. 12. 10. 4
04:18:11.001 -> NodeID: 3
04:18:11.001 -> Frequency: 915
04:18:11.367 -> Radio Started
04:18:11.367 ->  
04:18:11.367 -> 0 0 22 3 0 4 0 20 0 0 0 20 0 0 20 20


What I'm trying to understand is what in the bootloader could be causing this?
I thought maybe the flashmemory wasn't turned on correctly so I jumped a wire from 3v3 to its enable pin so the flash memory never actually lost power but the problem persisted.

If someone has some insight please please let me know.  I am really scratching my head here
5
Moteino / Re: using moteino r6 in extremely low-power project
« Last post by Felix on September 12, 2019, 12:12:15 PM »
My answers to your Qs:

Q1: The FLASH-MEM will use less than 1uA on average during sleep. There is a command to sleep it - flash.sleep().
An extra 1uA drain current is not going to hurt you significantly when your active current is several magnitudes more.

Q2: If your battery/power supply browns out during powering up anything, then you need a supply that can handle that inrush current demand from whatever your device you're powering, or another device that is less demanding. In the case of Moteino the brownout level is set to 2.7V or 1.8V for the 8mhz variant.
You can use a mosfet to cut power to the device, no need for fancy power switches.

Q3: If your circuit runs at a regulated voltage (through LDO) then you need to divide the battery voltage if it's higher than that voltage. Otherwise if your MCU runs directly from battery you can use the internal bandgap (1.1v for atmega328p) to determine the VCC.

A supercap may help when the surge from your power hungry device happens, but you have to keep it charged constantly, and I would not recommend using that in addition to a battery. For your application it sounds like a supercap is not feasible to be the only power supply.
6
Moteino / using moteino r6 in extremely low-power project
« Last post by d00m178 on September 11, 2019, 02:05:38 PM »
Hello all.
I need some advice for my project which I want to improve for better power consumptions and better stability.
Im using several old moteinos with RFM95 radiomodule and several Anarduinos (pretty the same MCU+RFM95) in my project.
And I want change all Anarduino to Moteino R6, because moteionos has better power consumption in sleepmode and better support in this forum.
So I going to buy at least 4 moteino r6 and 2 moteino m0 for testing.

I have 2 types of devices in my project:

 - "server" - each "server" device located outdoor, in the mountains region during winter season - from November till Marth approximatly.
 server has 10-15 termosensors ds18b20 and laser distance module.
 
 - "client" - portable device that I can use for send command to servers and receive  answers from them.
 
lets say - currently I have 10 servers and 2 clients devices.
 
"server" device works in this way - it sleep 1 minute, wakeup, check the current light from photoresistor, if it is the day time - it starts to listen radio broadcast for specific command from the "client" device.
if such command received - server start to measure temperature of snow and distance to snow surface.
then it send meausured data to client and go to sleep for 1 minute.
and then all starts again.
usually we ask servers for data 1-2 time per day - so most of the time servers are in sleep mode.
Server powered from LiPo batteries, and these days Im testing new power supply - LiFePo4 batteries + solar panel.
Most of my issues with devices - because of a power part of device, so my questions will be about this.

The main goal that I want to reach - it is the device which powered from battery+solar panel.
Device should live long in winter-snow conditions, so I think I need to use LiFePo4 18650 batteries, because my LiPo batteries in cold conditions start to do bad and usually it works 1-2 winter work seasons and then I need change it.

I have some specific questions and would be great if I have the exactly answers.

Q1: Im going to make an order Moteino's and would like to know - if I add Extra flash module (onboard 4Mbit) - will it consume power during sleep mode?
if so - I would rather not to add this module to order.

Q2: I use Laser Distance module like this:
https://ru.aliexpress.com/item/32792768667.html?spm=a2g0s.13010208.99999999.259.5b943c00k90TW5

Because I want to decrease power consumption as much as possible - LRF connected through mosfet IRLZ44N as shown on the picture attached, so it should power-off LRF before entering into sleep mode.

Code: [Select]
...
  pinMode(LASER_PWR, OUTPUT);
  digitalWrite(LASER_PWR, HIGH);
 
  // use LRF
 
  //go to sleep
  digitalWrite(LASER_PWR, LOW);

...

but I have an issue - sometime my device rebooting when I power on LRF module.
Seems it happens because of battery low level and MCU brown-out level, anyway - I want to minimize power drain by mosfet and want to change it to power switch,
for example to TPS27081ADDCR.
or another variant - use the AP2125 regulator with enable pin as I was adviced in this topic - https://lowpowerlab.com/forum/moteino/lifepo4-for-moteino/msg25439/

so my Question #2 - What would be the best variant in my case? And probably I need make some changes in my circiut? 


Q3: As I power my device from battery - I need to know the current level on voltage.
From the begining of my project I used the simple circuit like resistor divider to know the current level of power - R1, R2, C1 - on picture.

but I've seen this topic - https://lowpowerlab.com/forum/moteino-m0/battery-monitor/ - and would like to know more info about this battery-monitor and A7 pin.
Is it possible to know the voltage on battery without using separate resistor divider, only using pin A7?

Q4: the most difficult question for me - choose the type of batteris.
as i said - I use LiPo - mostly on my servers, and I have one server with test power supply based on LiFePo4 (4x18650 batteries) + solar panel and TP5000 charge module - but seems it doesn't work as expected.
I had to remove LDO from Moteino and power it from 3V3 pin.
but when LiFePo4 bundle become low - I often faced with "brow-out level" issue when I power-on LRF module.
So everything related to each other, so seems I need change battery type AND fix the way to control power for LRF and make the right way to know the current level of battery.

Also I've read this page about supercapacitor: https://lowpowerlab.com/2017/09/15/weathershield-supercapacitor-tiny-solar-cell/
probably I need to check this variant also, but Im unsure if such power supply is enought for my device consumption.

Thank you for reading this long story.
Hope that someone will advice useful ideas.

7
RF - Range - Antennas - RFM69 library / Re: LoRaWAN and LoRa
« Last post by ecliptic on September 10, 2019, 09:33:52 PM »
Thanks Felix for the always great information.  I had a feeling the hardware was expensive, and I personally would like to have control of the cloud.

Quote
I think these gateways also need to be able to run up to 8 channels in parallel.

I've looked at Semtech's preferred gateway chips (https://www.semtech.com/products/wireless-rf/lora-gateways/sx1301 for instance), and those chips are definitely expensive.  Not to mention, I would think the main processor needs to be beefy to in order to process the data from that many channels simultaneously.

I may look a little further into LoRaWAN's backend offering, but so far their hardware is really expensive.. but then again so was z-wave.  Again... thank you so much!
8
That's good to hear, I had assumed the code would block on either the sleep call or the WFI call which wouldn't allow the other to execute. I will most certainly give it a whirl. My C++ skills are pretty bad though, haha.

Thanks for the response! I'll report back my progress when I have a chance to work through this.
9
Moteino M0 / Re: Is it possible to wake the M0 by an external interrupt OR via RTCZero lib?
« Last post by Felix on September 10, 2019, 10:23:35 AM »
Looking at the example sketches there doesn't appear to be both of these functionalities combined anywhere.
Sorry I don't have an example of that specific combo, I reckon it must be doable though.
Did you try at all combining them in a sketch?
10
Moteino M0 / Re: Hangs after first Radio receive when using RTCZero to sleep
« Last post by Felix on September 10, 2019, 10:22:36 AM »
Thanks for the follow up, good to know its not something in the lib.
Interesting to see how many threads reveal char arrays (C strings), buffer overflows, memory leaks, and other variable mishaps as the root cause of some locking behavior. Extra care is needed with these data types, especially when manipulating them and using reference/dereference operators on them.
Pages: [1] 2 3 ... 10