New Firmware Release 1.096 beta

Manual Updates
Firmware Updates and beta releases
New Features requested by Users
User avatar
Pimaster
Site Admin
Posts: 1615
Joined: Fri Sep 14, 2012 9:50 am

Re: New Firmware Release 1.096 beta

Post by Pimaster » Tue Aug 26, 2014 1:06 am

Hi,

Thanks, that helps.
You are always welcome !!!

Would it be too difficult to add an I2C pin command or serial command to instantly cut power to the RPi?
No Problem with it, but please specify it more precise because we already have something like that.

This way I can make my own script that would run in the background, monitor the UPiS to see when it goes to battery, start a countdown, and then cut power to the RPi right before the UPiS enters low power mode.

What about this command already implemented

@SDWN <time> <P> RPi Powered after shutdown
@SDWN <time> <O> RPi not Powered after shutdown


or in the PICo implementation

3 or 0x03 fssd_timeout

4 or 0x04 fssd_type


5 or 0x05 fssd_batime



I tried something like this already, getting rid of the shutdown command in the fshut.py script so I could run a separate script that shuts down when it sees the UPiS enter battery mode, timing it so it happens right before low power mode. I started a stopwatch so I could see exactly how long it would take (with no shutdown at all, willing to risk a not-safe shutdown), but the UPiS never enters low power mode if the RPi doesn't shut down. Is it waiting to see the battery current drop first?

Probably you are drawing more current than specified. This is a variable that will be accessible to the user in next version




All I really want is the RPi to shut down immediately if power goes away, and then the UPiS to enter low power mode right after that. Then, when power comes back, everything starts back up- even if power comes back within just a couple seconds. My RPi is nothing but a web page in kiosk mode, so it doesn't take more than a second or two to shut down; I wish the minimum for the "File Safe Shut Down Procedure Time Out" (0x6b 3) wasn't as long as 15 seconds.

Is there anything I can do with I2C pin monitoring and commands to make this happen, or will I have to wait until more changes have been made to the firmware?

If you are not satisfied with solution we already implements, give me about 3-4 days to think and propose you new one

Warmest Regards
Pi Master
Warmest Regards
PiM
---
Designing with Mentor Graphics PADS - www.pads.com
Please read and follow the PiForum rules
http://www.forum.pimodules.com/viewtopic.php?f=13&t=196
---
nickglowsindark
Posts: 5
Joined: Fri Jul 25, 2014 4:31 pm

Re: New Firmware Release 1.096 beta

Post by nickglowsindark » Thu Aug 28, 2014 6:22 pm

I have set fssd_timeout and fssd_batime to their minimum values. After switching off the input power, it takes about 35-40 seconds for the RPi to power off and the UPiS to enter the low power state. If the power returns at any point during this time, the RPi will not restart automatically, which is my biggest concern and something I think you said you were planning to address in a future firmware version.

In the meantime, I have wired up a 40-second power-on-delay relay to the input power, so that even if power is switched off and immediately back on, the UPiS has time to get all the way to the low power state before turning back on, which has fixed everything. I would like to not have to rely on an extra piece of electronics for the future, though, and I'm looking forward to seeing what sort of changes I'll see in future updates.

Also, one other thing that is very minor- I would love to see a molded plastic case, maybe with a DIN rail on the back, for the UPiS. I purchased the clear plastic case and liked it very much, but discovered that it is very fragile and accidentally snapped one of the small plastic legs. I am hoping to mount the whole unit in a piece of industrial equipment that uses DIN rails for its electronics; I looked at trying to attach a DIN rail adapter to your case, but it would not stay very well without breaking the plastic. I ended up buying one of these (http://www.hitaltechusa.com/products-pa ... pberry-pi/) and then cutting out holes for the connections and switch. If my project is ultimately successful, I could end up needing 30 or more of these, and all that cutting will get very tedious. Do you know if there are any plans for different case styles in the future?
User avatar
Pimaster
Site Admin
Posts: 1615
Joined: Fri Sep 14, 2012 9:50 am

Re: New Firmware Release 1.096 beta

Post by Pimaster » Thu Aug 28, 2014 9:28 pm

Hi,

I have set fssd_timeout and fssd_batime to their minimum values. After switching off the input power, it takes about 35-40 seconds for the RPi to power off and the UPiS to enter the low power state. If the power returns at any point during this time, the RPi will not restart automatically, which is my biggest concern and something I think you said you were planning to address in a future firmware version.
We are working on it. This is not a bug, there is missing implementation of it, due to structure of the firmware. We are working on that and expect to release within this incoming week

In the meantime, I have wired up a 40-second power-on-delay relay to the input power, so that even if power is switched off and immediately back on, the UPiS has time to get all the way to the low power state before turning back on, which has fixed everything. I would like to not have to rely on an extra piece of electronics for the future, though, and I'm looking forward to seeing what sort of changes I'll see in future updates.
OK

Also, one other thing that is very minor- I would love to see a molded plastic case, maybe with a DIN rail on the back, for the UPiS. I purchased the clear plastic case and liked it very much, but discovered that it is very fragile and accidentally snapped one of the small plastic legs. I am hoping to mount the whole unit in a piece of industrial equipment that uses DIN rails for its electronics; I looked at trying to attach a DIN rail adapter to your case, but it would not stay very well without breaking the plastic. I ended up buying one of these (http://www.hitaltechusa.com/products-pa ... pberry-pi/) and then cutting out holes for the connections and switch. If my project is ultimately successful, I could end up needing 30 or more of these, and all that cutting will get very tedious. Do you know if there are any plans for different case styles in the future?

Look, for the existing UPiS the answer is no. Sorry about that.
However as you probably know, we are working on a new 3 models of UPiS, that will be released within September. They will be B+ mechanical compatible, as also HAT compatible


For them, the answer is YES, and will be as extension (spacer) for the molded case done by the ModMyPi.
https://www.modmypi.com/shop/modmypi-mo ... case-black
All I/O as also switch will be placed on the same side where RPi HDMI is existing (following HAT specifications)

We will also release a plexi type (similar to the previous one for the B+ and new UPiS)


As you are interesting for an industrial type Pi, I just inform you that we are also working on something like you are asking for, but it takes about 2 months from now. It will be based on the Compute Module.


http://www.forum.pimodules.com/viewforum.php?f=11

Please also check our pool for the new UPiS and vote for the I/O and other functionality of them

Thank you and Kind Regards
Pi Master
Warmest Regards
PiM
---
Designing with Mentor Graphics PADS - www.pads.com
Please read and follow the PiForum rules
http://www.forum.pimodules.com/viewtopic.php?f=13&t=196
---
Graham S
Posts: 47
Joined: Fri Feb 07, 2014 12:07 am

Re: New Firmware Release 1.096 beta

Post by Graham S » Sat Aug 30, 2014 1:27 pm

1.096 bug?

If I start with the following:
  • EPR Powering UPiS
  • Pi booted and running
  • Normally Open (NO) relay Open (default)
Then I trigger file safe shutdown, with EPR power still applied, the Pi correctly shuts down but after shutdown the UPiS NO relay changes state to closed on its own.

Should the relay not remain as set via PiCo/@RON/@ROFF as long as the UPiS has power applied?

I've not yet tried removing EPR power from the UPiS to see if the relay then opens again, because its difficult to test with my current test set-up, but I'm guessing it will open again as energising the relay would draw power from the UPiS battery and cause a rapid discharge.

Either the relay should maintain its commanded state, or worst case return to its NO default, when the Pi is shutdown with power applied. Without this I don't really have full control of the relay.

In my application the relay is used to switch power to USB hardware using power drawn from a much larger battery. If the relay closes when the Pi is off this causes the USB hardware to eventually exhaust the larger battery which isn't being charged.
Graham S
Posts: 47
Joined: Fri Feb 07, 2014 12:07 am

Re: New Firmware Release 1.096 beta

Post by Graham S » Sat Aug 30, 2014 2:55 pm

After further testing, it looks to me like the relay is behaving like normally closed and not normally open. Did I not understand the manually correctly?

:? Very confused
Graham S
Posts: 47
Joined: Fri Feb 07, 2014 12:07 am

Re: New Firmware Release 1.096 beta

Post by Graham S » Sat Aug 30, 2014 3:31 pm

Would it be possible to make the PiCo 6B register 0x05 (fssd_batime) a word rather than a byte?

With the 1.096 firmware its only possible to run on battery for 254 seconds before shutting down, this is just 4 minutes and 14 seconds and doesn't let you exploit the full capacity of the UPiS battery to run the Pi for longer periods. To do this I'd need to monitor the battery myself with a script, which defeats the point of this timer. With a 16 bit register it would be possible to run for up 65534 seconds, which is 18 hours, 12 minutes and 14 seconds. I'd be likely to use 30 minutes (1800 seconds).

Am I correct in assuming the battery getting to its minimum (3.7V) would trigger a file safe shutdown even if fssd_batime hadn't expired?

It would also be nice to add another register called fssd_minvolt, which would trigger a file safe shutdown when the battery discharged to a certain voltage rather than an absolute minimum of 3.7 volts.

Both these options could work together to trigger a safe shutdown while leaving reserve charge in the UPiS battery.

On the flip side it would also be nice to have a register which prevented the UPiS from leaving LPR mode until the battery reached a certain voltage, even if power was applied. This would prevent the UPiS booting up the Pi until there was a safe reserve in the battery to allow it to run for a while if power was lost again; think solar/wind power where the power supply could be very intermittent. Maybe this is what you have in mind for EPR_hyst?

Of these three, making 0x6B register 0x05 16bit would very much be my priority.

Graham
Graham S
Posts: 47
Joined: Fri Feb 07, 2014 12:07 am

Re: New Firmware Release 1.096 beta

Post by Graham S » Sat Aug 30, 2014 4:22 pm

Graham S wrote:After further testing, it looks to me like the relay is behaving like normally closed and not normally open. Did I not understand the manually correctly?

:? Very confused
Seems like the UPiS remembers the relay state and resumes whatever it was set too whenever the Pi is running (not the LPR/ERP/USB mode, but the Pi actually running), but whenever the Pi is off the relay is closed. Looks like the relay is normally closed and not normally open?
User avatar
Pimaster
Site Admin
Posts: 1615
Joined: Fri Sep 14, 2012 9:50 am

Re: New Firmware Release 1.096 beta

Post by Pimaster » Mon Sep 01, 2014 3:36 am

Hi Graham,

I will answer in details Monday evening.
Warmest Regards
Pi Master
Warmest Regards
PiM
---
Designing with Mentor Graphics PADS - www.pads.com
Please read and follow the PiForum rules
http://www.forum.pimodules.com/viewtopic.php?f=13&t=196
---
User avatar
Pimaster
Site Admin
Posts: 1615
Joined: Fri Sep 14, 2012 9:50 am

Re: New Firmware Release 1.096 beta

Post by Pimaster » Tue Sep 02, 2014 2:13 am

Hi,
Please find my answer in the text


Would it be possible to make the PiCo 6B register 0x05 (fssd_batime) a word rather than a byte?
Yes, it is possible. However, if you need more time, usually can leave the battery to discharge completely and then it will shutdown the RPi. So, the reason we selected to have 8 bit variable was that user will need shorter time only if it must be significant shorter.

With the 1.096 firmware its only possible to run on battery for 254 seconds before shutting down, this is just 4 minutes and 14 seconds and doesn't let you exploit the full capacity of the UPiS battery to run the Pi for longer periods. To do this I'd need to monitor the battery myself with a script, which defeats the point of this timer. With a 16 bit register it would be possible to run for up 65534 seconds, which is 18 hours, 12 minutes and 14 seconds. I'd be likely to use 30 minutes (1800 seconds).
We will, but not sure if it will be in this ongoing version of the firmware

Am I correct in assuming the battery getting to its minimum (3.7V) would trigger a file safe shutdown even if fssd_batime hadn't expired?
Not exactly, the minimum is 3.3 V, and then it trigger the FSSD.
The 3.7V is Nominal Voltage of the battery, and it feels (the battery) very well if has such voltage. ;)


It would also be nice to add another register called fssd_minvolt, which would trigger a file safe shutdown when the battery discharged to a certain voltage rather than an absolute minimum of 3.7 volts.
We can, but it could be overdose I think, as in any case we have the automatic FSSD when the battery is 3.3V (due to fact that we need to preserve some battery energy for the RTC).

Both these options could work together to trigger a safe shutdown while leaving reserve charge in the UPiS battery.
More or less we have it implemented, but just with fixed 3.3V instead of your proposed variable level.

On the flip side it would also be nice to have a register which prevented the UPiS from leaving LPR mode until the battery reached a certain voltage, even if power was applied. This would prevent the UPiS booting up the Pi until there was a safe reserve in the battery to allow it to run for a while if power was lost again; think solar/wind power where the power supply could be very intermittent.

The point is that, we at the beginning plan to have this device much simpler, but during the time, we have been asked to add many extra options that make the firmware more and more complicated. We even ware obligated to re-write parts of the firmware in order to decrease the size of the hex code. Actually we are running on a 82% of the IC, and need to add also promised the encryption and some other promised options.
Therefore we need to be carefully with the updates because it is going to be more and more difficult, mainly to the size of the IC Flash, that force us to be more and more non typical C writers and many times Assembly writers in order to save space.

Maybe this is what you have in mind for EPR_hyst?
The hyst is for the solar panel users.

Of these three, making 0x6B register 0x05 16bit would very much be my priority.
We will do it.

Graham

Warmest Regards
Ioannis
Warmest Regards
PiM
---
Designing with Mentor Graphics PADS - www.pads.com
Please read and follow the PiForum rules
http://www.forum.pimodules.com/viewtopic.php?f=13&t=196
---
User avatar
Pimaster
Site Admin
Posts: 1615
Joined: Fri Sep 14, 2012 9:50 am

Re: New Firmware Release 1.096 beta

Post by Pimaster » Tue Sep 02, 2014 2:17 am

Graham S wrote:
Graham S wrote:After further testing, it looks to me like the relay is behaving like normally closed and not normally open. Did I not understand the manually correctly?

:? Very confused
Seems like the UPiS remembers the relay state and resumes whatever it was set too whenever the Pi is running (not the LPR/ERP/USB mode, but the Pi actually running), but whenever the Pi is off the relay is closed. Looks like the relay is normally closed and not normally open?

The actual implementation of the Relay is NC.

Warmest Regards
Ioannis
Warmest Regards
PiM
---
Designing with Mentor Graphics PADS - www.pads.com
Please read and follow the PiForum rules
http://www.forum.pimodules.com/viewtopic.php?f=13&t=196
---
Post Reply