D455 Linux depth variation over time

Required Info

Camera Model
D455

Firmware Version
()

Operating System & Version
Ubuntu 18.04

Kernel Version (Linux Only)

Platform
PC

SDK Version

Language
C++

Segment

Issue Description
Hi,
I have a d455 camera that's fit to look down the floor. I ran it for 12 hours and calculated the floor depth 5 minutes once for same region of interest with no change in external lighting conditions.
Starting depth value: 1700mm
Depth value after 12 hours: 1715mm
The values kept on increasing from 1700 to 1715mm for 12 hours. Is there any possibility to avoid such behaviour?
Thanks.

Hi @rghl3  If the camera position and the lighting conditions remain constant, are there changes in the temperature during that 12 hour period (the air temperature of the environment that the camera is in or the internal ASIC and Projector temperatures of the camera).

Hi @MartyG-RealSense,
The projector temperature has varied from 35 to 41 degrees and asic temperature from 42 to 45 degrees.

Whilst your ASIC and Projector temperatures are very high, they are probably not high enough to introduce a hardware malfunction that could account for the measurement increases over time.
Your description suggests that it is a linear, predictable increase in distance error over time rather than random fluctuations.
If you have consistent lighting conditions 24 hours a day in the location that the camera is used in then you could try disabling auto-exposure and use a fixed exposure value (such as the camera's default depth exposure of '8500') to see whether it provides more stable measurement.

Hi @MartyG-RealSense ,

use a fixed manual exposure value (such as the camera's default depth exposure of '8500') to see whether it provides more stable measurement over long-term periods.

My use case requires the camera to be placed at any location over a longer period of time. So I am not sure of how much the manual exposure would affect the depth output. Nevertheless, I will try it and confirm if it provides stable measurement.

Your description suggests that it is a linear, predictable increase in distance error over time rather than random fluctuations.

I could observe a behavior where the depth value decreases when the temperature increases and vice versa.

Projector temperature( in degree celsius)
Depth value(in mm)

35
1688

28
1693

Is there any way to avoid this behavior or is this expected?

If your use case requires the camera to be placed in any location and operate over a long-term period then it would be best to have auto-exposure enabled in order to automatically adjust to the current environmental conditons.
I have not seen a case of a distance measurement rise and fall that corresponds predictably with a change in temperature.
The mounting position that you describe (looking down to the floor) suggests that the camera is used in an indoor environment and so high environmental temperature (air temperature) is not present in the locations where the camera will be installed.  Can you confirm this, please?
If the D455 is looking down at the floor, have you mounted it to the ceiling via the tripid screw-thread on the base of the camera?  And is there any air that might be being pushed down from your ceiling into the ventilation grille on the base of the camera?  The purpose of ventilation grilles is to allow hot air to escape from the inside of a device to the outside of it, so pushing air into the grille may result in overheating due to disturbing the internal airflow of the device, preventing it from exhausting from the casing properly.

The mounting position that you describe (looking down to the floor) suggests that the camera is used in an indoor environment and so high environmental temperature (air temperature) is not present in the locations where the camera will be installed. Can you confirm this, please?

Yes, the camera is used in an indoor environment usually with room temperature of 25 to 35 degree celsius.

Thank you very much.  The indoor room temperature could be classified as ranging from hot to very hot then.
The data sheet document for the 400 Series cameras states about exceeding 35 degrees C: "The Intel RealSense Depth Camera D400 Series camera can function above the 35 degrees C max ambient temperature when powered with degradation in performance and no guarantee of the camera meeting the depth quality metric".
This seems to be a situation where an active cooling solution external to the camera would work best.  The data sheet document has the following commentary about this subject:
"While heat pipes and liquid cooling solutions offer great advantages, they also increase the complexity of system integration substantially.  The use of a fan with direct air flow to the depth camera (back mounting surface 2xM3 screws) is preferable".

Hi @rghl3  Do you require further assistance with this case, please?   Thanks!

Hi @MartyG-RealSense ,
I got held up in a different task.Hence, the delay in response.

The Intel RealSense Depth Camera D400 Series camera can function above the 35 degrees C max ambient temperature when powered with degradation in performance and no guarantee of the camera meeting the depth quality metric.

I tested d415 camera and observed the same behaviour of increasing depth values with decreasing temperatures.
I started at 30 degree celsius and cooled the camera down till 10 degree celsius. I could observe the depth values increasing as temperature reduced.
I would like to know if there is a possibility for me to maintain the same depth value within the operating temperature range.

If your target depth value is 1700 mm, and during your earlier test it became 1688 mm when temperature increased to 35 degrees C and 1693 when temperature decreased to 28 degrees C, this suggests that depth error increases as temperature increases.  Can you confirm whether this is correct, please?
It is worth noting that there will be a certain margin of error in the depth measurements, as error increases linearly over distance (a principle called RMS error).  Information about RMS error can be found in the section of Intel's camera tuning guide linked to below.
https://dev.intelrealsense.com/docs/tuning-depth-cameras-for-best-performance#section-verify-performance-regularly-on-a-flat-wall-or-target
However, ideally you do want to minimize the possibility of the margin of error in the measurement increasing further due to temperature rise.   As you are using the camera in an indoor environment with varying room temperatures of 25 to 35 degrees C (ranging from hot to very hot), this suggests that the cooling solution should either be one that is constantly powerful or increases its cooling efforts as temperature increases (like a computer cooling fan that spins harder as operating temperature rises).
What method did you use to cool the camera to 10 degrees please?

If your target depth value is 1700 mm, and during your earlier test it became 1688 mm when temperature increased to 35 degrees C and 1693 when temperature decreased to 28 degrees C, this suggests that depth error increases as temperature increases. Can you confirm whether this is correct, please?

Yes.I could observe the above behavior.

What method did you use to cool the camera to 10 degrees please?

I mistakenly mentioned as cooling the camera. I cooled down the room temperature to 10degrees and not the camera. The camera projector temperature is almost 10 degree Celsius hotter than the room temperature. So I assume the camera projector temperature to be 20 degrees, during the above test.

It is worth noting that there will be a certain margin of error in the depth measurements, as error increases linearly over distance (a principle called RMS error)

The above behaviour was observed even for a height of 1000mm.

If the measured depth error at a certain temperature range is always consistent then you could read the camera's temperature with program scripting and apply a correction.  For example, if the measurement at 35 degrees is 1715 mm instead of the correct 1700 mm then the rough logic could be:
if projector temperature > 30 then depth_mm_corrected = depth_mm - 15

Since multiple depth levels are involved, we don't have sufficient data for how much depth varies at each level. So 1715 instead of 1700 may be 1305 and 1300.
Is there a specific projector temperature range within which the camera performance doesn't degrade if temperature is varied within that range?

Essentially this is an environmental problem that is external to the camera hardware.  As discussed earlier, it therefore could benefit from some kind of custom cooling / refrigeration solution that surrounds the camera or is mounted adjacent to it.
Intel have validated the camera for projector temperatures up to 35 degrees C.  Beyond that temperatures, no guarantees about performance and depth quality can be made.  So if predictable performance is vital then assuming 35 degrees to be the ideal maximum projector temperature to avoid exceeding if possible is recommendable.
How is the camera mounted in the face-down position?  Is it on the end of a robot arm?

We have mounted the camera on a vertical pole as of now and fit the camera facing down.

Is the pole metal?  If it is, that could be conducting heat from the room and passing it to the camera through the mounting point in addition to the heat that the camera casing absorbs.  Is the bottom of the pole low enough to touch with the hand and feel how hot it is?

SDK version 2.43.0 has just been released.  For the D455 it adds "a compensation mechanism intended to mitigate the effect of thermal propagation in optics.  When active (default = On) it will track and adjust Depth and RGB calibration parameters automatically".
https://github.com/IntelRealSense/librealsense/releases/tag/v2.43.0

Is the bottom of the pole low enough to touch with the hand and feel how hot it is?
The pole is made of a metal.The pole doesn't seem to be hot enough to feel.

SDK version 2.43.0 has just been released
I will try this version and update you if this solves.

Hi @rghl3  Do you have an update that you can provide about this case, please?  Thanks!

I am yet to test the above. I will close and re-open once I go back to that.

Okay @rghl3 that is no problem to re-open later if you need to.  Thanks for the update!

Hi @MartyG-RealSense,

SDK version 2.43.0 has just been released

The above sdk version seems to solve the varying depth values at different temperatures to a considerable extent.
The same behavior occurs for d415 camera also(increasing depth with decreasing temperature and vice versa). The release note mentions thermal optimization works only for d455.
Is there any possibility of thermal optimization, working for d415 camera also?

I am not familiar with the mechanics of the Thermal Compensation feature.  In one of the links associated with the feature in the release notes though, mention is made of only the D455 having a thermal monitor.

Is there a possibility in future for Thermal compensation feature to be included in d415 also?

I will seek advice from Intel about your question @rghl3

Hi @rghl3  Intel have no information to provide about future plans for this feature.

Hi @rghl3  Bearing in mind the above comment that there is no further information that can be provided regarding your question, do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.


Expand vectors to 4 components using compile time switch

This adds a new define LUA_VECTOR_SIZE to luaconf.h. Possible values for it are 3 (default) and 4. When the vector size is 4, extra data in tagged value will be expanded by 4 bytes to make room for float4 vectors (this will increase tagged value to 24 bytes in total due to alignment) and all VM vector ops are patched to work with 4 components.
I've verified that unit and conformance tests pass on MSVC.
resolves Roblox/luau#196

Please note the following fix I did to luaO_nilobject initialization. I think the same bug exists in master too (it initializes 'extra' incorrectly with LUA_TNIL).
https://github.com/Roblox/luau/pull/214/commits/8c2ea74f9eff06eb073e1f2a6ae679c9bf108857

I'm a tiny bit worried that this will bitrot if it doesn't have any unit tests.
That said, since we're talking about a compile-time flag, those unit tests are going to be something of a hassle to write.
Thoughts?

I'm wondering if we can make sure that our vector.lua test is in a state where it passes in both 3-vec and 4-vec configuration (via something like a conditional in the test that selects the right group of tests?). Overall I'm not too worried about this though because the surface area of the change is pretty small... but it would be nice to make sure that when the configuration is enabled, our conformance tests still pass and at least something checks that the .w component isn't totally dropped.

(for example, we went the same route with LONGJMP config - it's a compile time option that we currently don't test with every commit, but it does work with our conformance tests and we even have a test that would break if we broke that option deeply)

I agree unit tests would be nice to have. Although making them bullet proof would require compiling and testing both versions (LUA_VECTOR_SIZE 3 and 4). I'm out of office until Monday, but I will look into this when I get back.

I think it'd be fine to have the tests pass in either build and to have at least one test that checks .w in vec4 config even if we don't run both builds during continuous integration - if we see regression with this in the future we can always introduce extra build options.


Add tests for fileio

Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[x] If my change requires a change to the documentation, I have updated the documentation accordingly.
[x] I have added tests to cover my changes.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Describe changes

Added tests for our fileio functionality.
Fixed places where get_grandparent and get_parent were being called inside the codebase, since I fixed this in fileio to what makes sense.

@bcdurak and/or @htahir1 would appreciate your eyes on this. intersects with tfx for obv reasons and I want to be sure I didn't approach this in the wrong way.


generate_tfrecord give me Windows fatal exception: access violation

hello everybody, at the moment i do "python generate_tfrecord" i get this message, do you have any idea of what is the problem?
Windows fatal exception: access violation
Current thread 0x00000a20 (most recent call first):
File "C:\Users\Dougdaddyboy\Anaconda3\envs\tensorflow1\lib\site-packages\tensorflow\python\lib\io\file_io.py", line 84 in _preread_check
File "C:\Users\Dougdaddyboy\Anaconda3\envs\tensorflow1\lib\site-packages\tensorflow\python\lib\io\file_io.py", line 122 in read
File "generate_tfrecord.py", line 47 in create_tf_example
File "generate_tfrecord.py", line 92 in main
File "C:\Users\Dougdaddyboy\Anaconda3\envs\tensorflow1\lib\site-packages\absl\app.py", line 251 in _run_main
File "C:\Users\Dougdaddyboy\Anaconda3\envs\tensorflow1\lib\site-packages\absl\app.py", line 300 in run
File "C:\Users\Dougdaddyboy\Anaconda3\envs\tensorflow1\lib\site-packages\tensorflow\python\platform\app.py", line 40 in run
File "generate_tfrecord.py", line 101 in

I have the same problem.

My fine_tune_checkpoint directory set wrong in faster_rcnn_inception_v2_pets.config. After revised, it works fine.

Same here.

Maybe you can re-check there are corresponding files within the "images" under object_detection folder.

Hello, same here. Have you understood what was the matter?

Same here...

Did you use the command line written at the beginning of the 'generate_tfrecords.py' file? If you did so and it got you that error try to add the following argument to your command line:
--image_dir=/images (or wherever you put your images)
I had the same problem and this worked for me

Oh I solved this! Actually I don't know exactly what was the problem, but I changed my version of tensorflow, python, cuda, and cudnn, and then I could finish. It was a hard work, but version seems to be very important...
This is what I used for your information.
TensorFlow 1.8.0
Python 3.6
Cuda 9.0
CuDNN 7.6.3 for Cuda9.0
...and of cource, GitHub Models Repository Commit for tensorflow 1.8!
(+alpha, I deleted so many files to spare enough space of my Drives)
As the tutorial says, as of tensorflow 1.9, the folder does not include train.py file. There seem to be so many differences in the files according to the versions and I tried in a way that seemed easier. So I chose 1.8.
I hope it helps.

If you train your own data, check the csv table you generated. Maybe there is no .jpg in filename.

In my case, I am creating my own object detactor, First the problem was that I had few images without its xml, I created this script to detect them.
`import glob
TEST_IMAGES_PATH='C:/Users/Asus/Desktop/my_tf_model/images/test/'
for image_path in glob.glob(TEST_IMAGES_PATH + '*.jpg'):
xml=glob.glob(image_path[:-4]+'.xml')
if xml==[]:
print('JPG problem with : '+ image_path)
for xml_path in glob.glob(TEST_IMAGES_PATH + '*.xml'):
jpg=glob.glob(xml_path[:-4]+'.jpg')
if jpg==[]:
print('XML problem with : '+ xml_path)`
After solving that problem, I still had the problem,  I added "print(row['filename']) in generate_tfrecord.py to see where the program is blocking to realise that I had an xml file that has the wrong image filename.
In my opinion, try first to run the generate_tfrecord with few images, if it works, then you are sure your problem isn't realited to environement and versions but with the data.


Making dropTable work again and deprecating it

There is little point of having yet another way of dropping a table. Migrations should happen only through the Table class.
refs #1367

It is a nice convenience method however, that doesnt need anything else.

@dereuromark I'm questioning here the need to drop NOW!!!, by doing so you deprive phinx the ability to do a better job for you


Better bulk data handling in OnSystemRequest

Fixes #86.
Signed-off-by: Mike Burke<EMAIL_ADDRESS>

This is technically a hotfix since no APIs have changed, but I wanted to make sure the appropriate parties have time to review, so I'm marking this one for the regularly scheduled review.
I ran unit tests on this PR and all tests were passed, so I'm confident that it's good to go.
Only open question is whether the body field needs to conform to this weird logic in the existing code.
JSONObject jLayer1 = null;
String sReturn = null;
try
{
    if (httpreqparams != null)
    {
        jLayer1 = myJSONObj.getJSONObject("HTTPRequest");
        sReturn = jLayer1.getString("body");
        return sReturn;
    }
    else if (myJSONObj != null)
    {
        return myJSONObj.toString();
    }
    else
    {
        return null;
    }
}
catch (Exception e)
{
    return null;
}

The first if statement is the "normal" case where it reads the body from the HTTPRequest JSON message.  However, if the HTTPRequest JSON message doesn't exist, it is assumed the entire bulk data is the body.  Does the new code need to conform to this requirement?  Does the request ever come across with just the body like this?  Is there different behavior in different message protocol versions?
Any info I could get on this behavior would be very useful.  Thanks.

I ran a round testing with the changes and so far things look good.  As far as the weird logic you mentioned, we should be safe in removing this… at one point the json inside of the binary data that we received from the module for a policy table update request differed in format from the json (in the bin data) that we received for a vehicle update request.  Since the module now provides the data in the same format for both types of onSystemRequests, we can safely remove the else if that you referenced.

Thanks @mrapitis.  I will remove my TODO comment and this PR should be all set.


Hide like button

It would be nice to be have the option to hide the "Like" heart button with the likes count, since clicking it sometimes results in "this person liked" popping up in other peoples's feeds. And it removes some of the social gaming of counting likes as well since you can't see the numbers anymore.
Just an idea!

Closing as this extension is now deprecated: https://github.com/sindresorhus/refined-twitter/commit/8dd9df749d3a4e82c95b2bd6628c8d65f0f72e6c


Gen2 Move Path Does Not Work For Non-Root Paths That Start With /

Preflight Checklist

[X] I have installed the latest version of Storage Explorer.
[X] I have checked existing resources, including the troubleshooting guide and the release notes.
[X] I have searched for similar issues.

Storage Explorer Version
1.19.0
Platform
Windows
OS Version
No response
Architecture
x64
Build Number
No response
Regression From
1.17.0
Bug Description
Move a file or folder in gen2 to a non-root directory, start the path in the dialog box with a slash.
Steps to Reproduce
See description.
Actual Experience
It doesn't work.
Expected Experience
It should work.
Additional Context
No response

@v-xianya @v-limu while I'm working on a fix for this, can y'all add a (p1 or p2) test case for this? Basically, for Gen2 rename, it should not matter if what you input starts/ends with a / or not.
For example, if I'm moving .DS_Store into test:

All of these inputs should work:

untitled folder/test
/untitled folder/test
untitled folder/test/
/untitled folder/test/

@MRayermannMSFT
Got it. thank you for the reminder. we added this to regular test cases and marked as P1.

Verified this issue on the latest build 20210521.3. Fixed.


⚠ Bofrost.at has degraded performance

In 4d6244b, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1525 ms

Resolved: Bofrost.at performance has improved in 395a662.


QA 1.6 fixes and cleanups

Various cleanups and fixes made during QA for 1.6 release

Fixed PIC test, and made it larger
Fixed NaiveBayes test
Fixed ALSTest in Scala to use implicitPrefs
Removed recommend all in ALSTest
Updated config:

elastic net params
removed numPoints, numColumns from clustering and used numExamples, numFeatures instead

set tol to 0 in elastic net tests

CC: @mengxr

LGTM. Merged into master.


Make #[derive(Bundle)] work on tuple structs

Objective

This change allows one to derive the Bundle trait on all kinds of structs that is Record, Tuple and Unit(not that useful by itself, but for completioness sake) structs instead of just record structs.

Do we really want to allow unit types be bundles? This would almost certainly be a user error to do that

Prior to this PR empty records are already allowed which would also be user errors to derive Bundle on.
I suppose it would make sense to emit a compile error for structs with no fields in general?

I suppose it would make sense to emit a compile error for structs with no fields in general?

I agree with this. If we find some obscure use case where this makes sense we can add this functionality back in :)

Sorry for leaving this in limbo for far too long :(

No worries, I am just not interested in updating the PR any longer. And truthfully spoken, given the huge backlog of PRs on the project I wouldn't expect it to get merged until its outdated again.
If someone wants to update it be my guest though 👍


Allow to specify custom ATS/ETS2 launch options

This PR adds --game-options= option. The specified game options are passed to ATS/ETS2.
Closes #163.
Example: --game-options="-nointro -64bit -sysmouse"
@Lucki Don't forget to compile truckersmp-cli.c and replace original truckersmp-cli.exe with compiled executable before testing this.

I've seen quite often -- as a delimiter between argument options that are handed through scripts to underlying stuff. For example the steam runtime is doing that in the other PR.
Is there any reason you did that differently, are there any pros or cons?

About the reason why I use -- when using run command?
Here is an example:
$ LANG=C /path/to/SteamLinuxRuntime_soldier/run ls -F /
pressure-vessel-wrap[xxxxxx]: E: Unknown option -F

Without --, -F option is passed to run (pressure-vessel-wrap) and it fails due to unknown option.
$ /path/to/SteamLinuxRuntime_soldier/run -- ls -F /
bin@  etc/   lib@    lib64@      proc/  sbin@  tmp/  var/
dev/  home/  lib32@  overrides/  run/   sys/   usr/

With --, run doesn't use -F as the option for run.
So the answer is "because it is necessary".

You misunderstood me.
I wanted to know why you decided against
truckersmp-cli [options] -- -nointro -64bit -sysmouse

in favor to
truckersmp-cli [options] --game-options="-nointro -64bit -sysmouse"

The pressure vessel example was just there to elaborate where I've seen the option delimiter used before.

I wanted to know why you decided against ...

I simply didn't have the idea to do it like this. However, it uses positional arguments and the usage is hard to change in the future.
Actually I'm considering allowing users to start ETS2MP with truckersmp-cli [options] start ets2mp (like git commit, ip address, etc.), but if we use positional arguments here it would be hard.

truckersmp-cli [options] -- -nointro -64bit -sysmouse

Users don't need to type --game-options=
Users don't need to quote options when using multiple launch options
Users need to use -- before options
Developers need to change the behavior of ArgumentParser object
I personally don't like to use positional arguments only for game options (but I think truckersmp-cli [options] -- start ats -nointro -64bit -sysmouse is ok)

truckersmp-cli [options] --game-options="-nointro -64bit -sysmouse"

Users don't need to type -- before options
Users need to type --game-options=
Users need to quote options when using multiple launch options
Easy to add the feature in Python script
Positional arguments can be freely used in the future

Which do you think is better?

Which do you think is better?

I personally don't like to use positional arguments only for game options (but I think truckersmp-cli [options] -- start ats -nointro -64bit -sysmouse is ok)

This looks awkward to me. So let's go with truckersmp-cli [options] --game-options="-nointro -64bit -sysmouse" then. That'll make it clear what gets handed to the game.

Basically seems to work but I've encountered this strange thing:
./truckersmp-cli start ets2mp --gamedir "/mnt/gamehub/native2proton/Euro Truck Simulator 2/" --enable-d3d11 --game-options "-64bit"
usage: truckersmp-cli [-h] [-a] [-b VERSION] [-d] [-e] [-g DIR] [-i APPID] [-l LOG] [-m DIR] [-n NAME] [-o DIR] [-p] [-s] [-u] [-v] [-w] [-x DIR] [--activate-native-d3dcompiler-47] [--check-windows-steam] [--disable-proton-overlay] [--downgrade] [--game-options OPTIONS] [--native-steam-dir DIR] [--self-update]
                      [--singleplayer] [--skip-update-proton] [--use-wined3d] [--wine-desktop SIZE] [--wine-steam-dir DIR] [--without-wine-discord-ipc-bridge] [--version]
                      [{start,update,downgrade,updateandstart,ustart,downgradeandstart,dstart,none}] [{ets2mp,ets2,ats,atsmp,none}]
truckersmp-cli: error: argument --game-options: expected one argument

These were fine:
./truckersmp-cli start ets2mp […] --game-options="-64bit"
./truckersmp-cli start ets2mp […] --game-options "-64bit -nointro"

Also interesting while searching for possible parameter:
There's -homedir "D:\profile\path" possible which may be interesting for us to make the profile folder which contains saves and mods more accessible.


range_test and sge_test not picked up by tox due to being executable

While developing some new functionality in luigi.tools.range I ran the range_test.py file manually and noticed that it had multiple failing tests that were unrelated to my changes, even on a clean master with no changes at all. Strangely, tox goes through and the build passes anyway. This happens because the whole file is ignored. The reason the file is ignored is because it is set as executable (755) which apparently causes tox to ignore it.
Steps to reproduce

Run complete test suite as usual and watch everything go through: tox
Run only the range_test.py file and it has multiple issues, FAILED (failures=2, errors=6): cd test && python -m unittest range_test
Change file permissions: chmod 644 range_test.py
Run tox suite again and this time the file is picked up, failing with the same problems:

======================================================================
ERROR: Verify that you can still programmatically set of param as string
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/lena/projects/github/spotify/luigi/test/range_test.py", line 1385, in test_old_month_instantiation
    self.assertEqual(expected_task, list(range_task._requires())[0])
IndexError: list index out of range

======================================================================
ERROR: test_param_name (range_test.MonthInstantiationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/lena/projects/github/spotify/luigi/test/range_test.py", line 1423, in test_param_name
    self.assertEqual(expected_task, list(range_task._requires())[0])
IndexError: list index out of range

======================================================================
ERROR: test_param_name_with_inferred_fs (range_test.MonthInstantiationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/lena/projects/github/spotify/luigi/test/range_test.py", line 1439, in test_param_name_with_inferred_fs
    self.assertEqual(expected_task, list(range_task._requires())[0])
IndexError: list index out of range

======================================================================
FAIL: Verify that you can still use Range through CLI
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/lena/projects/github/spotify/luigi/test/range_test.py", line 1407, in test_month_cli_instantiation
    self.assertEqual(MyTask(month_param=datetime.date(1934, 12, 1)).secret, 'yay')
AssertionError: 'some-value-to-sooth-python-linters' != 'yay'
-------------------- >> begin captured logging << --------------------
luigi: INFO: logging already configured
luigi.scheduler: DEBUG: Starting pruning of task graph
luigi.scheduler: DEBUG: Done pruning task graph
--------------------- >> end captured logging << ---------------------

======================================================================
FAIL: test_of_param_commandline (range_test.MonthInstantiationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/lena/projects/github/spotify/luigi/test/range_test.py", line 1481, in test_of_param_commandline
    self.assertEqual(MyTask.state, ('bar', 5))
AssertionError: Tuples differ: (None, None) != ('bar', 5)

First differing element 0:
None
'bar'

- (None, None)
+ ('bar', 5)

The only executable files I could find were range_test.py and contrib/sge_test.py.
Solution
We need to chmod the concerned files to match the others (644) and fix the failing tests. If we can't fix them right now we need to temporarily ignore the individual tests and create new Github issues. I am in progress of doing this but wanted to report the error in case anyone else encounters the problem.

@lallea FYI

Thanks @lnsndn for debugging and fixing. Probably my bad.
I reviewed and concluded that the tests are wrong, but the implementation is right. The tests were probably passing before https://github.com/spotify/luigi/pull/2666 got merged.

Nice catch!!

Thank you @Tarrasch!
By the way, isn't this error kind of problematic, that tox just silently ignores executable files? How would we prevent it from happening again? I can definitely see someone accidentally modifying file permissions again, tests go through and no one notices anything.

It is worrying yes. Not sure If I know a general solution to this though. (that's also practical :))


🐛 image distorded at startup and a bit zoomed in

What's happening?
First i'm sorry i didn't try to reproduce the issue in the VisionCamera Example app but I've never managed to make the VisionCamera Example app run, i've always had build issues !
I have this weird bug where when I open the camera page, the image feedback of my back camera is completly distorted, here is an image :

Now this problem is completly temporary because if i then flip the camera twice (back=>front=>back) it disappears :

Note that it also disappears if i leave the app and open it back imedialtly.
==============================================================
Also, another problem I have which my be linked to this one (i'm not 100% sure) is that the camera is by default way more zoomed in  that my default OS camera.
Here is the zoom with react-native-vision-camera :

and here is the default OS camera zoom ;

Note that this also happens if I use  "<Camera resizeMode={"contain"} ..../>
Reproduceable Code
import React, { useRef, useState } from "react";
import { TouchableOpacity, View } from "react-native";
import { useCameraDevice, Camera, useCameraPermission } from "react-native-vision-camera";

import { useIsFocused } from "@react-navigation/native";
import { useAppState } from "@react-native-community/hooks";

export default function CameraScreen_Test({}): JSX.Element {
  const isFocused = useIsFocused();
  const appState = useAppState();
  const isActive = isFocused && appState === "active"; // for more informations https://react-native-vision-camera.com/docs/guides/lifecycle
  const [selectedCamera, setSelectedCamera] = useState("back"); // Start with the back camera

  const camera = useRef<Camera>(null);

  const device = useCameraDevice(selectedCamera);

  console.log(JSON.stringify(device, (k, v) => k === "formats" ? [] : v, 2))

  return (
    <View style={{ flex: 1, backgroundColor: "pink" }}>
      <TouchableOpacity
        onPress={() => {
          setSelectedCamera((currentCamera) => (currentCamera === "back" ? "front" : "back"));
        }}
        style={{ width: 50, height: 50, borderRadius: 25, position: "absolute", bottom: 100, alignSelf: "center", backgroundColor: "red" }}
      ></TouchableOpacity>
      <Camera
        ref={camera}
        zoom={device.neutralZoom}
        enableZoomGesture={true}
        resizeMode={"cover"}
        style={{
          width: "100%",
          alignSelf: "center",
          height: "70%",
          backgroundColor: "blue",
        }}
        device={device}
        isActive={isActive}
        photo={true}
        torch={"off"}
      />
    </View>
  );
}

Relevant log output
nsor mode: -1 Camera position: 1 Camera lens_type: 0 Camera spectrum: -1 load default tuning  Usecase: 0 Sensor mode: -1 Camera position: 1 Camera lens_type: 0 Camera spectrum: -1
01-29 00:43:10.997   909 12359 W libgcam : [ae_helper.cc:575]: FinalizeAeImpl: Desired short TET 33966.00 outside of the achievable shot range, clamped to 6120.31
01-29 00:43:10.997   909 12359 W libgcam : [ae_helper.cc:581]: FinalizeAeImpl: Desired long TET 33966.00 outside of the achievable shot range, clamped to 6120.31
01-29 00:43:11.001   909 12329 W G3ACoordinator: tuning_manager.h:68: Node type 2, Tuning key not found:  Usecase: 13 Sensor mode: -1 Camera position: 1 Camera lens_type: 0 Camera spectrum: -1 load default tuning  Usecase: 0 Sensor mode: -1 Camera position: 1 Camera lens_type: 0 Camera spectrum: -1
01-29 00:43:11.048   909 12381 W Lyric   : external_auto_focus_controller_proxy.cc:1192: In EarlyInterrupt: Set focus happens 79169956 ns after start of exposure time
01-29 00:43:11.057   909 12359 W libgcam : [ae_helper.cc:575]: FinalizeAeImpl: Desired short TET 33966.00 outside of the achievable shot range, clamped to 6120.31
01-29 00:43:11.057   909 12359 W libgcam : [ae_helper.cc:581]: FinalizeAeImpl: Desired long TET 33966.00 outside of the achievable shot range, clamped to 6120.31
01-29 00:43:11.061   909 12329 W G3ACoordinator: tuning_manager.h:68: Node type 2, Tuning key not found:  Usecase: 13 Sensor mode: -1 Camera position: 1 Camera lens_type: 0 Camera spectrum: -1 load default tuning  Usecase: 0 Sensor mode: -1 Camera position: 1 Camera lens_type: 0 Camera spectrum: -1
01-29 00:43:11.063   909 12392 W Lyric   : external_auto_focus_controller_proxy.cc:435: No SW PD stats are valid; Status: INTERNAL: xx_pdaf_results_payload has null payload
01-29 00:43:11.071  3918 12238 D ModemODPMPoller: Current Modem ODPM (mw): 47, threshold: 800
^C

Camera Device
{
  "formats": [],
  "sensorOrientation": "landscape-right",
  "hardwareLevel": "full",
  "maxZoom": 8,
  "minZoom": 0.5304937958717346,
  "maxExposure": 24,
  "supportsLowLightBoost": true,
  "neutralZoom": 1,
  "physicalDevices": [
    "wide-angle-camera",
    "ultra-wide-angle-camera",
    "telephoto-camera"
  ],
  "supportsFocus": true,
  "supportsRawCapture": true,
  "isMultiCam": true,
  "minFocusDistance": 9.800000093460085,
  "minExposure": -24,
  "name": "BACK (0)",
  "hasFlash": true,
  "hasTorch": true,
  "position": "back",
  "id": "0"
}

Device
Google Pixel 7a - Android 14
VisionCamera Version
3.8.2
Can you reproduce this issue in the VisionCamera Example app?
I didn't try (⚠ your issue might get ignored & closed if you don't try this)
Additional information

[ ] I am using Expo
[ ] I have enabled Frame Processors (react-native-worklets-core)
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

Duplicate of https://github.com/mrousavy/react-native-vision-camera/issues/2380.

Duplicate of #2380.

I'm sorry I didn't know this issue was already addressed, but I still have the issue with the camera being zoomed in. Any ideas why ?


Refactoring long lines and removing the pylint exception.

Refactors all lines that violate the max_line_length rule in .pylintrc to be less than 120 characters.
Removes the now-irrelevant pylint exception for line length.
This PR does not remove the invalid-name linter exception, since you would have to rename the log variable to LOG and I'm assuming you do not want to do that. This PR does, however, refactor the invalid-name exception to be inline instead of taking up two extra lines, though.

Pylint report: Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

Looks great!


Update storage-sync-files-deployment-guide.md

Under the section to create a new storage sync service, I have updated the text to say "Create a resource" as it does not say "New" in portal anymore.

@mzsalam : Thanks for your contribution! The author, @wmgries, has been notified to review your proposed change.

@mzsalam Thank you for this correction! Signoff approval was submitted internally, so I'm merging now.


[Azure] Problem loading build options after moving bot app service to different subscription

Hi, I'm really not sure if this is the place for an issue like this, so excuse me if I'm wrong.
Deployment Environment: Azure App Service
Issue Description
I have a Bot App Service in the Azure Portal. I had it in a subscription under a resource group called "pnibot", then I had to move it to another subscription, now under a resource group called "PNI". The app itself is working properly.
My problem is that when I click the resource to open it and get the build options (the view that lets you open the code editor or download the source code), I get this error:
"The Resource 'Microsoft.Web/sites/pnibot' under resource group 'pnibot' was not found."
As I said the bot works properly, and I can open the other tabs with no problem (Channels, Analytics, Settings), but I need to be constantly opening this view to work on the code and sometimes download it, so this is a tedious issue. Can anyone help?
Reproduction Steps

Move an Azure Bot Service to a different subscription
Try to open the "Build" view of the resource

Expected Behavior
Being able to open the code editor and download the source code
Actual Results
Get error: "The Resource 'Microsoft.Web/sites/pnibot' under resource group 'pnibot' was not found."

Thank you for reporting this issue.
Please try using https://resources.azure.com/  There might be something that did not get moved correctly.

@osvc96 We currently do not support moving a bot from one resource group and subscription to another.  You are going to have to create a new bot on the Dev portal.  We do plan to support this before our Preview status is removed (coming soon).
Do you still have your code or do you need help retrieving it?

@JasonSowers I do have it, it can still be accessed but it's way less convenient (I have to go to Settings -> advanced settings ->App Service Editor). It's strange since the bot does work properly, it's only the Build tab that doesn't work.

I agree it seems strange, but I assure you there is nothing that can be done on your end to remedy this.  This scenario is just not supported at this time, unfortunately.  Best of luck and let me know if you run into any other troubles.  We would be happy to help get you up and running again.


Factory.time.time value is not equal to the shown value

Hi!
First of all, thanks for the awesome library!
You can reproduce the issue on http://flipclockjs.com/ as well, just call clock.stop() and see the value of clock.time.time. It is 1 second after the shown value.
The reason of that is that the Face objects in flip methods create time value before calling base. Incrementation happens in base, but it display the received time.
I could fix it by passing just the display methods for base, but some kind of MVC pattern could be useful here :)
Thanks!
Tomi

This should be fixed in the new js-es6 branch of the library. I completely rewrote this library, and by the sounds it, I have tested for this and it should be fixed. Open a new issue if you ever use the new version of the library.


[stable/ark] Timing problem (CRDs not available immediately)

Is this a request for help?:
No.
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Bug Report
Version of Helm and Kubernetes:
❯ helm version
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}

❯ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-04T04:49:22Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.5", GitCommit:"753b2dbc622f5cc417845f0ff8a77f539a4213ea", GitTreeState:"clean", BuildDate:"2018-11-26T14:31:35Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
stable/ark
What happened:
Deploying stable/ark fails with:
Error: validation failed: unable to recognize "": no matches for kind "BackupStorageLocation" in version "ark.heptio.com/v1"

What you expected to happen:
For the deployment to work.
How to reproduce it (as minimally and precisely as possible):
Deploy it.
Anything else we need to know:
From: https://github.com/heptio/velero/issues/1195

I think there is sort of a timing problem with the helm chart, where the CRD backupstoragelocations.ark.heptio.com is not "ready" before helm tries to create an "instance" of it. Trying to run it usually errors out with:
Error: validation failed: unable to recognize "": no matches for kind "BackupStorageLocation" in version "ark.heptio.com/v1"
It only works very rarely and randomly. Why we think this is a timing issue is because we get the same behaviour, if we try to deploy ark without helm by simply running the following from a script:
kubectl apply -f config/common/00-prereqs.yaml
kubectl apply -f config/aws/05-ark-backupstoragelocation.yaml
kubectl apply -f config/aws/06-ark-volumesnapshotlocation.yaml
kubectl apply -f config/aws/10-deployment.yaml
kubectl apply -f config/aws/20-restic-daemonset.yaml

But if we run the prereqs first/separately and the other stuff with a couple of seconds of delay, it works. Running the prereqs manually and then using the helm charts doesn't work because of the behaviour @Sam123ben describes.
At least this is our observation and theory. If this can be reproduced, I can also open a separate issue here or in the helm chart's repository. Please advise.

I am observing this behavior as well.

Fixed by https://github.com/helm/charts/pull/12031?

Not fixed as near as I can tell. Still getting this error with stable/velero --version 1.0.0

So far, I haven't been able to reproduce this on GKE or KinD with master, 1.0.0, or 1.0.1.
My kubernetes version on GKE:
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.6-gke.10", GitCommit:"aaf0906400b5fc1d858ce0566a571e4f3ed06b9f", GitTreeState:"clean", BuildDate:"2019-03-30T19:30:48Z", GoVersion:"go1.10.8b4", Compiler:"gc", Platform:"linux/amd64"}

And in KinD:
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980be
eeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a0876
eeState:"clean", BuildDate:"2019-03-20T16:54:39Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

Helm versions:
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}

@wskulley What version of kubernetes are you running? I saw this problem when I was working on the velero install command and put all resources into a single YAML document, but had added ready checks to the install command to avoid that. 1.0.0 of this chart should have avoided this with the crd-install hook, so I'm not sure what environment differences are affecting the timing.

kops based in aws, kops versions up to 1.11.1:
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-26T00:04:52Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.9", GitCommit:"16236ce91790d4c75b79f6ce96841db1c843e7d2", GitTreeState:"clean", BuildDate:"2019-03-25T06:30:48Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
and
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-26T00:04:52Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.6", GitCommit:"b1d75deca493a24a2f87eb1efde1a569e52fc8d9", GitTreeState:"clean", BuildDate:"2018-12-16T04:30:10Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Helm version:
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}


(Deno as any).setRaw changed to (Deno as any).stdin.setRaw

Deno.setRaw will throw an error as of Deno 1.26.0
https://github.com/denoland/deno/pull/15797
I simply updated to Deno.stdin.setRaw.
This change was labelled (unstable) but was merged back on Sept. 28, Deno.setRaw now throws Deno.setRaw is not a function Please correct me if I'm wrong in assuming these needed to be updated.

Thank you for this! I took a break from maintenance here as my day job got busy but I'm going to work to resolve this. It looks like this API has further changed, and we should be able to fix this easily and remove the need for the unstable flag. I've added a bug to track this work here: https://github.com/keegandonley/input-deno/issues/27. Let me know if you're interested in working on it still (after over a year, sorry 🤣) otherwise I can take a look this evening.


Add token bearer for swagger

Add token bearer to swagger
fix swagger request URL

@AnandChowdhary  plz review

Is there no way to globally add @ApiBearerAuth? Because we support both API keys and access token, and this PR only adds access tokens, right?

⚠ This PR has not seen any activity in the past 2 months so I'm marking it as stale. I'll close it if it doesn't see any activity in the coming week.


Blur + Taskbar segments (enabled) hides the clock and battery percentage

There is no option to view the clock, battery, WiFi status and tray when Style -> Blur with Taskbar Segments enabled.

v<IP_ADDRESS> solves it.
Is there a way to make the Start Button background on Windows 10 transparent with the main Style -> Blur + Taskbar segments enabled?


Alias Insert to Upsert

It might be useful to be able to alias 'insert' commands as 'upsert' in Phoenix.
My specific reason for this is that I was trying to use DbDeploy for managing changes and internally it's coded to 'insert' into the changelog table.  There's no doubt other situations where it could be useful to insert.
A true/false property might be a good idea?
On the other hand, I can code around this and/or contact Graham the main contributor at DbDeploy.
What do people think?
Julian

Hi, I'm trying to use dbdeploy for Hbase db change management and I'm running into this issue, please see the error below. Has this been fixed? Can someone help me fix this issue, pls?

Hello,
Phoenix moved to Apache a few years ago, so this site is no longer active.
If you have Phoenix questions, please subscribe to our Apache email list(s)
and ask there: https://phoenix.apache.org/mailing_list.html
Thanks,
James
On Feb 18, 2016, at 7:24 AM, hepcibha<EMAIL_ADDRESS>wrote:
Hi, I'm trying to use dbdeploy for Hbase db change management and I'm
running into this issue, please see the error below. Has this been fixed?
Can someone help me fix this issue, pls?
—
Reply to this email directly or view it on GitHub
https://github.com/forcedotcom/phoenix/issues/387#issuecomment-185772391.

thanks !


How we can decode progressive jpeg image from internet?

I want to decode image in such a way that at beginning low quality image is shown and after that quality increases progressively.

You should encode your image with "progressive" option, and then you may decode the image like this: https://github.com/ibireme/YYImage#image-decoder
See also: https://github.com/ibireme/YYWebImage

HI what would be the difference between using YYImage vs YYWebImage ?


Downstream Role Template Handler

Stack from ghstack (oldest at bottom):

#47660
#47572
#47456
-> #47455

Closing in favour of https://github.com/rancher/rancher/pull/48114


unexpected EOF while looking for matching ...

I'm using Arch/Manjaro.
$ pacman -Qs eabi
local/arm-none-eabi-binutils 2.36.1-2
    A set of programs to assemble and manipulate binary and object files for the ARM EABI (bare-metal) target
local/arm-none-eabi-gcc 10.3.0-1
    The GNU Compiler Collection - cross compiler for ARM EABI (bare-metal) target
local/arm-none-eabi-newlib 4.1.0-1
    A C standard library implementation intended for use on embedded systems (ARM bare metal)
$ pacman -Qs openocd
local/openocd 1:0.11.0-1
    Debugging, in-system programming and boundary-scan testing for embedded target devices

Whenever I try to build I get this error:
$ make -C libopencm3
make: Entering directory '/home/cf/src/opendps/libopencm3'
  GENHDR  include/libopencm3/vf6xx/irq.json
  GENHDR  include/libopencm3/lpc17xx/irq.json
  GENHDR  include/libopencm3/lpc43xx/m0/irq.json
  GENHDR  include/libopencm3/lpc43xx/m4/irq.json
  GENHDR  include/libopencm3/sam/3a/irq.json
  GENHDR  include/libopencm3/sam/3u/irq.json
  GENHDR  include/libopencm3/sam/3n/irq.json
  GENHDR  include/libopencm3/sam/3x/irq.json
  GENHDR  include/libopencm3/sam/d/irq.json
  GENHDR  include/libopencm3/sam/3s/irq.json
  GENHDR  include/libopencm3/efm32/lg/irq.json
  GENHDR  include/libopencm3/efm32/gg/irq.json
  GENHDR  include/libopencm3/efm32/g/irq.json
  GENHDR  include/libopencm3/efm32/tg/irq.json
  GENHDR  include/libopencm3/lm3s/irq.json
  GENHDR  include/libopencm3/stm32/f3/irq.json
  GENHDR  include/libopencm3/stm32/l1/irq.json
  GENHDR  include/libopencm3/stm32/f1/irq.json
  GENHDR  include/libopencm3/stm32/f2/irq.json
  GENHDR  include/libopencm3/stm32/l4/irq.json
  GENHDR  include/libopencm3/stm32/f4/irq.json
  GENHDR  include/libopencm3/stm32/f0/irq.json
  GENHDR  include/libopencm3/stm32/l0/irq.json
  GENHDR  include/libopencm3/stm32/f7/irq.json
  GENHDR  include/libopencm3/lpc13xx/irq.json
  BUILD   lib/stm32/f0
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 2: syntax error: unexpected end of file
make: *** [Makefile:64: lib/stm32/f0] Error 2
make: Leaving directory '/home/cf/src/opendps/libopencm3'

Any ideas why that is?

$ cd libopencm3
$ make clean V=1
  CLNHDR  include/libopencm3/vf6xx/irq.json
  CLNHDR  include/libopencm3/lpc17xx/irq.json
  CLNHDR  include/libopencm3/lpc43xx/m0/irq.json
  CLNHDR  include/libopencm3/lpc43xx/m4/irq.json
  CLNHDR  include/libopencm3/sam/3a/irq.json
  CLNHDR  include/libopencm3/sam/3u/irq.json
  CLNHDR  include/libopencm3/sam/3n/irq.json
  CLNHDR  include/libopencm3/sam/3x/irq.json
  CLNHDR  include/libopencm3/sam/d/irq.json
  CLNHDR  include/libopencm3/sam/3s/irq.json
  CLNHDR  include/libopencm3/efm32/lg/irq.json
  CLNHDR  include/libopencm3/efm32/gg/irq.json
  CLNHDR  include/libopencm3/efm32/g/irq.json
  CLNHDR  include/libopencm3/efm32/tg/irq.json
  CLNHDR  include/libopencm3/lm3s/irq.json
  CLNHDR  include/libopencm3/stm32/f3/irq.json
  CLNHDR  include/libopencm3/stm32/l1/irq.json
  CLNHDR  include/libopencm3/stm32/f1/irq.json
  CLNHDR  include/libopencm3/stm32/f2/irq.json
  CLNHDR  include/libopencm3/stm32/l4/irq.json
  CLNHDR  include/libopencm3/stm32/f4/irq.json
  CLNHDR  include/libopencm3/stm32/f0/irq.json
  CLNHDR  include/libopencm3/stm32/l0/irq.json
  CLNHDR  include/libopencm3/stm32/f7/irq.json
  CLNHDR  include/libopencm3/lpc13xx/irq.json
if [ -d lib/stm32/f0 ]; then \
	printf "  CLEAN   lib/stm32/f0\n"; \
	make -C lib/stm32/f0 clean SRCLIBDIR="/home/cf/src/opendps-leo/libopencm3/lib\" || exit ; \
fi;
/bin/sh: -c: line 3: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 5: syntax error: unexpected end of file
make: *** [Makefile:75: lib/stm32/f0.clean] Error 2

I think the backslash right before the " is the issue, since it escapes it.
So something in this line maybe:
SRCLIBDIR:= $(subst $(space),\$(space),$(realpath lib))
realpath on the shell gives me a correct path without backslash though...
I think I'm really close, but not there yet...

Ok, it seems to work by simply removing the insertion of the backslash.
#SRCLIBDIR:= $(subst $(space),$(space),$(realpath lib))
SRCLIBDIR:= $(realpath lib)

Ok, building works fine now, as far as I can tell.
I've connected the PCB with a STLinkV2 and using other software I can read the chip ID and type, so the connection seems to be working (I've flashed STM8/32 type µCs before, so not a total noob).
But if I try to connect using openocd, like described in the howto/documentation, I get this:
$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
DEPRECATED! use 'swj_newdap' not 'hla newtap'
[... 331 lines more of that ...]
embedded:startup.tcl:265: Error: Infinite eval recursion
in procedure 'script'
at file "embedded:startup.tcl", line 26
in procedure 'swj_newdap' called at file "target/stm32f1x.cfg", line 38
in procedure 'hla' called at file "target/swj-dp.tcl", line 28
in procedure 'swj_newdap' called at file "embedded:startup.tcl", line 265
in procedure 'hla' called at file "target/swj-dp.tcl", line 28
[... 331 times the same over and over again ...]
at file "embedded:startup.tcl", line 265

Am I doing something basically wrong here?

Build problems with libopencm3 is probably handled more efficiently in the libopencm3 repo.
As for the OpenOCD issue I noted last week that the script syntax changed some time ago. The maintainers probably had good reasons but nevertheless it's a bit of a bother if you ask me. I guess you are using the scripts from the openocd dir of this repo. Try upgrading the scripts or downgrading the version of OpenOCD you are using.

Thank you for your reply!
I found out, that OpenOCD starts, when I first change into the opendps folder and run
openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
It doesn't work in the openocd/scripts folder (errors, see above post).
Now it seems to work as expected:
$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.210000
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections

I could then connect to port 4444 and erase the flash of the µC.
After that building and flashing a DPS3003 with firmware and bootloader worked also fine.
Still not exactly sure about the Makefile thing, but it seems to work just fine without the backslash.
Thank you for your work on this! :)
OT: I was asking myself if I put in a ESP8266 for WiFi, is it possible/sensible to power it from the serial "port" voltage pin on the DPS PCB or is it recommended to power it externally from the supply voltage (using a regulator)? It seems to be enough to power the Bluetooth module, but I guess that also draws less current.

I've decided to give up on this. Although I really appreciate all the work that has been done by everyone involved, for me, there are too many questions marks and missing documentation (or simply more people using it), at least with my device (DPS3003).
I've explicitly used the DPS3003 as "guinea pig", so I was ready to trash it. I guess there is no way to get the original firmware back on the µC?
I flashed the firmware, it kind of works, but the values shown in the display and set values are off, when measured. It needs calibration, but I couldn't really figure out how, at least not completely. Although I used the build options to select the correct device variant (DPS3003) the supplied calibration values didn't seem to work for mine.
I also had issues with the update over serial function. In the end, I had to reflash it using JTAG.
Sometimes I'm a bit impatient, so it is perfectly possible that some of these issues are my own fault. ;-)

I have a working DPS3003! If you like, I can send you my binaries for flashing. Also for me: It took some time to get it calibrated. I tried the method of dpsctl several times but did not succeed. Finally I wrote my own calibration software using VB.NET. The release I have been using is a little bit older (somewher in the middle of 2019 I think). Feel free to contact me again if you like!
Regards, Horst
Von: Christian Fiebig @.>
Gesendet: Samstag, 29. Mai 2021 17:45
An: kanflo/opendps @.>
Cc: Subscribed @.***>
Betreff: Re: [kanflo/opendps] unexpected EOF while looking for matching ... (#242)
I've decided to give up on this. Although I really appreciate all the work that has been done by everyone involved, for me, there are too many questions marks and missing documentation (or simply more people using it), at least with my device (DPS3003).
I've explicitly used the DPS3003 as "guinea pig", so I was ready to trash it. I guess there is no way to get the original firmware back on the µC?
I flashed the firmware, it kind of works, but the values shown in the display and set values are off, when measured. It needs calibration, but I couldn't really figure out how, at least not completely. Although I used the build options to select the correct device variant (DPS3003) the supplied calibration values didn't seem to work for mine.
I also had issues with the update over serial function. In the end, I had to reflash it using JTAG.
Sometimes I'm a bit impatient, so it is perfectly possible that some of these issues are my own fault. ;-)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/kanflo/opendps/issues/242#issuecomment-850853882 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AMPLUQSXRUNP57F4AGQEFDTTQEDYBANCNFSM45O2L3WQ .  https://github.com/notifications/beacon/AMPLUQQKJYSPNBK7VU32XDLTQEDYBA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK3P76Q.gif

Thank you for your offer, maybe I will get back to you about that!
Using dpsctl.py I've now completed the calibration process, but something is still off, the displayed input voltage jumps up and down, which it didn't do before. Also the display only flashes when I enable the output. But I will try it again.
At first I've used a generic USB to serial adapter (PL2303 IC) connected to RX/TX and some things worked (like --ping), but others don't. Now I've connected one of the "original" RDTech adapters (using a CH340 IC), which somehow seems to work better.
$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 --calibrate
For calibration you will need:
	A multimeter
	A known load capable of handling the required power
	A thick wire for shorting the output of the DPS
	2 stable input voltages

Please ensure nothing is connected to the output of the DPS before starting calibration!

Would you like to proceed? (y/n): y

Input Voltage Calibration:
Please hook up the first lower supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 2494

Please hook up the second higher supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 4992

Output Voltage Calibration:
Finding maximum output V_DAC value.......................... Done

Calibration Point 1 of 2, 10% of Max
Type measured voltage on output in mV: 3269

Calibration Point 1 of 2, 90% of Max
Type measured voltage on output in mV: 18653

Output Current Calibration:
Max output current of your DPS (e.g 5 for the DPS5005) in amps: 3
Load resistance in ohms: 10
Load wattage rating in watts: 100
Please connect the load to the output of the DPS, then press enter
Calibrating output current ADC............... Done

Constant Current Calibration:
Please short the output of the DPS with a thick wire capable of carrying 3.0A, then press enter

Finding maximum output A_DAC value.......................... Done
Calibrating output current DAC............... Done

Calibration Complete!

$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
	A_ADC_K = 0.9988852143287659
	A_ADC_C = -22.790977478027344
	A_DAC_K = 0.0
	A_DAC_C = 204.0
	V_ADC_K = 8.156081199645996
	V_ADC_C = -117.81263732910156
	V_DAC_K = 0.2129485160112381
	V_DAC_C = -287.1286926269531
	VIN_ADC_K = -49959.9921875
	VIN_ADC_C = 56819496.0
	VIN_ADC = 1134
	VOUT_ADC = 15
	IOUT_ADC = 5
	IOUT_DAC = 0
	VOUT_DAC = 0

When analyzing your calibration report I’ve found an error in two values:
    VIN_ADC_K = -49959.9921875
    VIN_ADC_C = 56819496.0

This are the values for input voltage calculation. They are expected to be much smaller than yours. In file dps_model.h you can find the values similar to your own specific device:
VIN_ADC_K shozld be around 16.8, means the max. calculatable input voltage is 16.8 * 4095 = 68.8V. DPS3003 are designed having an input voltage range of +6 … 40V.
And this is the second error I have found. The report shows input calibration voltages of ~ 2.5V and ~ 5V. Due to the specs of the device this is not enough!
Otherwise your reports also shows an output adc calibration voltage of ~3.2V and ~ 18.6V. That’s physically not possible because the DPS only has a step down converter.
I assume, your real input voltage is about 20V or higher?
So, please repeat your calibration. Appy the input voltage to your dps and measure this value with your DMM. Omit the smaller value and use it as 0.
Please find below as it should look now:
Von: Christian Fiebig @.>
Gesendet: Samstag, 29. Mai 2021 22:18
An: kanflo/opendps @.>
Cc: hseibel12 @.>; Comment @.>
Betreff: Re: [kanflo/opendps] unexpected EOF while looking for matching ... (#242)
Thank you for your offer, maybe I will get back to you about that!
Using dpsctl.py I've now completed the calibration process, but something is still off, the displayed input voltage jumps up and down, which it didn't do before. Also the display only flashes when I enable the output. But I will try it again.
At first I've used a generic USB to serial adapter (PL2303 IC) connected to RX/TX and some things worked (like --ping), but others don't. Now I've connected one of the "original" RDTech adapters (using a CH340 IC), which somehow seems to work better.
$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 --calibrate
For calibration you will need:
A multimeter
A known load capable of handling the required power
A thick wire for shorting the output of the DPS
2 stable input voltages
Please ensure nothing is connected to the output of the DPS before starting calibration!
Would you like to proceed? (y/n): y
Input Voltage Calibration:
Please hook up the first lower supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 2494
Please hook up the second higher supply voltage to the DPS now
ensuring that the serial connection is connected after boot
Type input voltage in mV: 4992
Output Voltage Calibration:
Finding maximum output V_DAC value.......................... Done
Calibration Point 1 of 2, 10% of Max
Type measured voltage on output in mV: 3269
Calibration Point 1 of 2, 90% of Max
Type measured voltage on output in mV: 18653
Output Current Calibration:
Max output current of your DPS (e.g 5 for the DPS5005) in amps: 3
Load resistance in ohms: 10
Load wattage rating in watts: 100
Please connect the load to the output of the DPS, then press enter
Calibrating output current ADC............... Done
Constant Current Calibration:
Please short the output of the DPS with a thick wire capable of carrying 3.0A, then press enter
Finding maximum output A_DAC value.......................... Done
Calibrating output current DAC............... Done
Calibration Complete!
$ ./dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
A_ADC_K = 0.9988852143287659
A_ADC_C = -22.790977478027344
A_DAC_K = 0.0
A_DAC_C = 204.0
V_ADC_K = 8.156081199645996
V_ADC_C = -117.81263732910156
V_DAC_K = 0.2129485160112381
V_DAC_C = -287.1286926269531
VIN_ADC_K = -49959.9921875
VIN_ADC_C = 56819496.0
VIN_ADC = 1134
VOUT_ADC = 15
IOUT_ADC = 5
IOUT_DAC = 0
VOUT_DAC = 0
—
You are receiving this because you commented.
Reply to this email directly,  https://github.com/kanflo/opendps/issues/242#issuecomment-850892886 view it on GitHub, or  https://github.com/notifications/unsubscribe-auth/AMPLUQS7LQRV6KDMZGH54CLTQFDWDANCNFSM45O2L3WQ unsubscribe.  https://github.com/notifications/beacon/AMPLUQXAGT2NGWK4SJJHGUTTQFDWDA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK3ZQVQ.gif

Ok, I've re-run everything with the best multimeter I have, hooked on a 2.2 Ohms load with 100W for measuring and successfully completed the --calibrate process.
The input voltage is showing up stable now in the LCD and doesn't jump around anymore.
Unfortunately the device won't output any voltage or current when I enable it. I tried CV with 12 Volts, no output. Display shows 0V 0A (which is correct but not expected).
I also tried to power a bunch of LEDs with constant current (80 mA, Voltage set to max, in CC mode) -- also no output.

@hseibel12: You're right the input voltage I entered was nonsense! I repeated the above mentioned calibration with about 6.5 V and 19 V. I additionally measured the exact value with my DMM and put in the actually value.

When analyzing your post I have found some mistakes in the calibration report! First please have a look to the file dps-model.h. The values for the input voltage calibration are to be expected somewhere like
Your values are much to high. I think you did an error with the input voltage calibration. Your values of approx.. 2.5 and 5 volts are much too low. The DPS3030 hat an input operation range of 6V to 40V DC. I had the same problems when trying to calibrate at the beginning.

This is the output I get now after calibration with the correct (and higher) input voltages (and all other) values:
$ dpsctl/dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
	A_ADC_K = 1.0069375038146973
	A_ADC_C = -83.07911682128906
	A_DAC_K = -1.3510895155839012e-17
	A_DAC_C = 245.0
	V_ADC_K = 8.158334732055664
	V_ADC_C = -119.56439208984375
	V_DAC_K = 0.21321184933185577
	V_DAC_C = -287.9895324707031
	VIN_ADC_K = 16.752090454101562
	VIN_ADC_C = 30.79538345336914
	VIN_ADC = 1134
	VOUT_ADC = 15
	IOUT_ADC = 0
	IOUT_DAC = 0
	VOUT_DAC = 0

The error is with the A-DAC_K. It should be around 0.12 not 0,00000000……
The formular for calculation is  Amp = mx + b
x ->  ADC-Count
m -> V_DAC_K
b -> V_DAC_C
this always calculates to around 0!
Von: Christian Fiebig @.>
Gesendet: Sonntag, 30. Mai 2021 11:53
An: kanflo/opendps @.>
Cc: hseibel12 @.>; Mention @.>
Betreff: Re: [kanflo/opendps] unexpected EOF while looking for matching ... (#242)
This is the output I get now after calibration with the correct (and higher) input voltages (and all other) values:
$ dpsctl/dpsctl.py --device /dev/ttyUSB0 --baudrate 9600 -cr
Calibration Report:
A_ADC_K = 1.0069375038146973
A_ADC_C = -83.07911682128906
A_DAC_K = -1.3510895155839012e-17
A_DAC_C = 245.0
V_ADC_K = 8.158334732055664
V_ADC_C = -119.56439208984375
V_DAC_K = 0.21321184933185577
V_DAC_C = -287.9895324707031
VIN_ADC_K = 16.752090454101562
VIN_ADC_C = 30.79538345336914
VIN_ADC = 1134
VOUT_ADC = 15
IOUT_ADC = 0
IOUT_DAC = 0
VOUT_DAC = 0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/kanflo/opendps/issues/242#issuecomment-850972467 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AMPLUQTNM4TXV44KUSTYCQDTQIDHTANCNFSM45O2L3WQ .  https://github.com/notifications/beacon/AMPLUQUBI7XS2I5GF74NKYDTQIDHTA5CNFSM45O2L3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGK4M6MY.gif

Ok, I give up.
The calibration process also doesn't seem to work correctly.
I reset the calibration data and tried manually setting VOUT_DAC by pressing M1 + M2 and enter the value, but that also doesn't generate any voltage output. Not sure if this option is broken or I don't understand how it works. My idea was to measure the values manually and then calculate the K and C values. Like it is described here:
https://leo.leung.xyz/wiki/DPS5005
But if I enter for example 50 for VOUT_DAC and enable the output, it still shows 0 Volts (even after resetting all calibration data to the defaults in the dps-model.h).
I think I put it in the trash, buy a new one and keep using the original firmware. I may not be perfect but at least it works. ;-)
Also the dpsctl.py script somehow differs in behavior from the description on this page:
https://johan.kanflo.com/upgrading-your-dps5005/
I can change the function mode, calibrate and stuff like that, but can't set any voltage or current with --voltage 3000 for example, using the serial connection. I can enable the device and ping it, though.
Also the --status option doesn't work or doesn't exist (anymore?).

I understand your frustration. Similar happened to me ….
Attached the binaries of my working device. If it generally works, I expect the calibration not being absolutely perfect. If this basically works, the reason should be in the version you are using or in the compilation process … But, if it does, I would not suggest to use the calibration routines of the distro. There are some reasons that may lead to your problems.

Sorry, forgot to say:
My files are working at the former baudrate setting of 115200 Baud! You should not use the original converter because it does not work at this higher baudrate. (I’ve been using very successfully a DIY FTDI-version!). If the files basically work, I can make a 9600 Buad version for you. Here’s the makefile I have been using for my binaries:
BINARY = opendps
Build with commandline interface rather than serial interface
COMMANDLINE := 0
The baudrate used for serial communications, defaults to 115200
BAUDRATE ?= 115200
Set build model, defaults to DPS5005
MODEL := DPS3003
Include splash screen
SPLASH_SCREEN := 0
Build wifi version (only change being that the wifi icon will start flashing
on power up)
WIFI := 0
Maximum current your DPS model can provide. Eg 5000mA for the DPS5005
This is usually set by MODEL but you can override it here
#MAX_CURRENT := 3000
Please note that the UI currently does not handle settings larger that 9.99A
Print debug information on the serial output
DEBUG ?= 0
Font file
METER_FONT_FILE ?= gfx/Ubuntu-C.ttf
METER_FONT_SMALL_SIZE ?= 18
METER_FONT_MEDIUM_SIZE ?= 24
METER_FONT_LARGE_SIZE ?= 48
FULL_FONT_FILE ?= gfx/ProggyClean.ttf
FULL_FONT_SMALL_SIZE ?= 16
Color space for the DPS display.
Near at the end of the calibration process, I get this (part of it):
Debug: Calculated DAC value: 204
Debug: iout_adc: 5 (sample #1)
Debug: iout_adc: 65534 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 4 (sample #4)
Debug: iout_adc: 65533 (sample #5)
Debug: iout_adc: 4 (sample #6)
Debug: iout_adc: 5 (sample #7)
Debug: iout_adc: 9 (sample #8)
Debug: iout_adc: 5 (sample #9)
Debug: iout_adc: 65534 (sample #10)
Debug: iout_adc: 5 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 1 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 5 (sample #15)
Debug: iout_adc: 65535 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 65534 (sample #18)
Debug: iout_adc: 4 (sample #19)
Debug: iout_adc: 5 (sample #20)
Debug: Average: 16387.1

Debug: Calculated DAC value: 204
Debug: iout_adc: 4 (sample #1)
Debug: iout_adc: 65534 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 65534 (sample #4)
Debug: iout_adc: 5 (sample #5)
Debug: iout_adc: 65533 (sample #6)
Debug: iout_adc: 65532 (sample #7)
Debug: iout_adc: 5 (sample #8)
Debug: iout_adc: 65535 (sample #9)
Debug: iout_adc: 5 (sample #10)
Debug: iout_adc: 4 (sample #11)
Debug: iout_adc: 1 (sample #12)
Debug: iout_adc: 5 (sample #13)
Debug: iout_adc: 0 (sample #14)
Debug: iout_adc: 4 (sample #15)
Debug: iout_adc: 4 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 4 (sample #18)
Debug: iout_adc: 5 (sample #19)
Debug: iout_adc: 4 (sample #20)
Debug: Average: 16386.4

Debug: Calculated DAC value: 204
Debug: iout_adc: 5 (sample #1)
Debug: iout_adc: 5 (sample #2)
Debug: iout_adc: 4 (sample #3)
Debug: iout_adc: 2 (sample #4)
Debug: iout_adc: 4 (sample #5)
Debug: iout_adc: 4 (sample #6)
Debug: iout_adc: 8 (sample #7)
Debug: iout_adc: 9 (sample #8)
Debug: iout_adc: 9 (sample #9)
Debug: iout_adc: 4 (sample #10)
Debug: iout_adc: 1 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 4 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 9 (sample #15)
Debug: iout_adc: 3 (sample #16)
Debug: iout_adc: 4 (sample #17)
Debug: iout_adc: 2 (sample #18)
Debug: iout_adc: 4 (sample #19)
Debug: iout_adc: 4 (sample #20)
Debug: Average: 4.75

Debug: Calculated DAC value: 204
Debug: iout_adc: 65535 (sample #1)
Debug: iout_adc: 6 (sample #2)
Debug: iout_adc: 5 (sample #3)
Debug: iout_adc: 6 (sample #4)
Debug: iout_adc: 5 (sample #5)
Debug: iout_adc: 1 (sample #6)
Debug: iout_adc: 4 (sample #7)
Debug: iout_adc: 65535 (sample #8)
Debug: iout_adc: 4 (sample #9)
Debug: iout_adc: 5 (sample #10)
Debug: iout_adc: 7 (sample #11)
Debug: iout_adc: 5 (sample #12)
Debug: iout_adc: 0 (sample #13)
Debug: iout_adc: 5 (sample #14)
Debug: iout_adc: 2 (sample #15)
Debug: iout_adc: 4 (sample #16)
Debug: iout_adc: 5 (sample #17)
Debug: iout_adc: 65534 (sample #18)
Debug: iout_adc: 5 (sample #19)
Debug: iout_adc: 65533 (sample #20)
Debug: Average: 13110.3

There are some "wrong" values, that mess up the average.
I wonder where they come from. I thought about removing the outliers, but that maybe only fix the symptom but not the actual issue.
All other readings seem to be fine:
For example:
Debug: Getting current reading at 4086.0000000000005 mV:
Debug: vout_adc: 594 (sample #1)
Debug: vout_adc: 595 (sample #2)
Debug: vout_adc: 595 (sample #3)
Debug: vout_adc: 595 (sample #4)
Debug: vout_adc: 595 (sample #5)
Debug: vout_adc: 594 (sample #6)
Debug: vout_adc: 596 (sample #7)
Debug: vout_adc: 594 (sample #8)
Debug: vout_adc: 595 (sample #9)
Debug: vout_adc: 595 (sample #10)
Debug: vout_adc: 595 (sample #11)
Debug: vout_adc: 595 (sample #12)
Debug: vout_adc: 595 (sample #13)
Debug: vout_adc: 594 (sample #14)
Debug: vout_adc: 595 (sample #15)
Debug: vout_adc: 596 (sample #16)
Debug: vout_adc: 596 (sample #17)
Debug: vout_adc: 595 (sample #18)
Debug: vout_adc: 595 (sample #19)
Debug: vout_adc: 596 (sample #20)
Debug: Average: 595.0

Debug: iout_adc: 2114 (sample #1)
Debug: iout_adc: 2112 (sample #2)
Debug: iout_adc: 2112 (sample #3)
Debug: iout_adc: 2114 (sample #4)
Debug: iout_adc: 2113 (sample #5)
Debug: iout_adc: 2116 (sample #6)
Debug: iout_adc: 2113 (sample #7)
Debug: iout_adc: 2124 (sample #8)
Debug: iout_adc: 2115 (sample #9)
Debug: iout_adc: 2117 (sample #10)
Debug: iout_adc: 2121 (sample #11)
Debug: iout_adc: 2113 (sample #12)
Debug: iout_adc: 2116 (sample #13)
Debug: iout_adc: 2113 (sample #14)
Debug: iout_adc: 2116 (sample #15)
Debug: iout_adc: 2122 (sample #16)
Debug: iout_adc: 2112 (sample #17)
Debug: iout_adc: 2113 (sample #18)
Debug: iout_adc: 2112 (sample #19)
Debug: iout_adc: 2115 (sample #20)
Debug: Average: 2115.15

or
Calibration Point 1 of 2, 10% of Max
Type measured voltage on output in mV: 3270
Debug: vout_adc: 416 (sample #1)
Debug: vout_adc: 415 (sample #2)
Debug: vout_adc: 415 (sample #3)
Debug: vout_adc: 415 (sample #4)
Debug: vout_adc: 415 (sample #5)
Debug: vout_adc: 415 (sample #6)
Debug: vout_adc: 415 (sample #7)
Debug: vout_adc: 415 (sample #8)
Debug: vout_adc: 416 (sample #9)
Debug: vout_adc: 415 (sample #10)
Debug: vout_adc: 415 (sample #11)
Debug: vout_adc: 415 (sample #12)
Debug: vout_adc: 415 (sample #13)
Debug: vout_adc: 415 (sample #14)
Debug: vout_adc: 415 (sample #15)
Debug: vout_adc: 415 (sample #16)
Debug: vout_adc: 416 (sample #17)
Debug: vout_adc: 416 (sample #18)
Debug: vout_adc: 415 (sample #19)
Debug: vout_adc: 416 (sample #20)
Debug: Average: 415.25

Calibration Point 1 of 2, 90% of Max
Type measured voltage on output in mV: 26430
Debug: vout_adc: 3254 (sample #1)
Debug: vout_adc: 3255 (sample #2)
Debug: vout_adc: 3255 (sample #3)
Debug: vout_adc: 3257 (sample #4)
Debug: vout_adc: 3257 (sample #5)
Debug: vout_adc: 3255 (sample #6)
Debug: vout_adc: 3257 (sample #7)
Debug: vout_adc: 3253 (sample #8)
Debug: vout_adc: 3256 (sample #9)
Debug: vout_adc: 3258 (sample #10)
Debug: vout_adc: 3257 (sample #11)
Debug: vout_adc: 3257 (sample #12)
Debug: vout_adc: 3255 (sample #13)
Debug: vout_adc: 3256 (sample #14)
Debug: vout_adc: 3258 (sample #15)
Debug: vout_adc: 3261 (sample #16)
Debug: vout_adc: 3257 (sample #17)
Debug: vout_adc: 3253 (sample #18)
Debug: vout_adc: 3256 (sample #19)
Debug: vout_adc: 3257 (sample #20)
Debug: Average: 3256.2

I assume this is an integer error. Just do not know where it comes from but please have a look to the below calculation (I used the values of the second block):
Original
Interger

Correct values

4
0

4

65534
65536

-2

5
0

5

65534
65536

-2

5
0

5

65533
65536

-3

65532
65536

-4

5
0

5

65535
65536

-1

5
0

5

4
0

4

1
0

1

5
0

5

0
0

0

4
0

4

4
0

4

5
0

5

4
0

4

5
0

5

4
0

4

Average:
16386,4
		2,4

I also have had errors with the original software. As the output of the step-down regulator contains noise which overlaps the DC-value we run into problems near zero:
If you subtract 1 from 0 the value of an 16 bit integer counts to 65535, on 2 it calculates 65534 and so on. This seems to be the result of an underrun error somewhere when subtracting an calibration offset from the adc-reading. See above table. I am sure the right column should be the correct values (Its’s average is 2.4 which is nearly Zero!). Logically this is much closer to your small DAC value (204). In your calibration the _DAC_C = 245.0 is the value for  0,00A.
I do not know where this happens. My workaround was modifying the original software mainly in the hw.c implementing a modified ADC_ISR and also averages for this values to reduce the impact of noise. If you like I can send you my files to look into and verify if this helps in your case.

The original issue was also addressed in the libopencm repo https://github.com/libopencm3/libopencm3/issues/1321


[core,gcc] fix earlyCapablityFlag handling

Only reply with flags that are currently activated on server

Replaced by #8629


Y-scroll when on bottom of the page

Describe the bug
When there is no scroll on page  (y-axe) or when the input element is at the end of the page, during calendar opening scroll appears. It's because menu is going from down and as written before, there is nothing bellow therefore this menu makes page longer.
To Reproduce
Steps to reproduce the behavior:

Install datepicker
Insert it to the end of the page and/or have a page without y-scroll
Click on input (open calendar)
See scroll error

Desktop & mobile (please complete the following information):

Firefox Developer edition, 100.0b7 (64-bit)

@KamilPesek Did you disable autoPosition, even if there is no space it should only flicker for a millisecond and not extend the page? I will fix that flicker if that is what you are referring to.

No, I can't disable it. Because if I disable it it will go
from

to

This issue is present since v2.4.0 as I said here : https://github.com/Vuepic/vue3-date-time-picker/issues/97#issuecomment-1046025217
If you add a "Lorem Ipsum" in front of the component so that component is lower in page, is not working, as you can see here:
https://stackblitz.com/edit/vuepic-vue-datepicker-jhtqsd?file=src%2Fcomponents%2FPlayground.vue

@ekkode Fixed it, it will be added in v3.2.0. You would need to replace :autoPosition="false" with alt-position="true" and add the :teleport="#exampleModal" since the wrapper element is fixed position wrapper, thus, standard calculating would not work here.

This will work strating form v3.2.0? Because now as you can see there is an error showing:

@ekkode Yes, from v3.2.0

@Jasenkoo
I have updated to v3.2.0 and the error is still there

@ekkode Sry, slight adjustments, teleport is a string prop and auto-apply boolean
Here is the working example


DO NOT MERGE: build check

Changes Unknown when pulling 3483f236ecbe35d1a56c5991bdaa300242976e6a on build_check into ** on master**.

Changes Unknown when pulling 3483f236ecbe35d1a56c5991bdaa300242976e6a on build_check into ** on master**.


A handy way to inject path parameters with the controller base route

Hello again, guys.
I want a handy way to build the following routes and successfully get the path parameters:

POST | /api/blogs/:blogId/posts/ | PostCtrl.addPost()
POST | /api/blogs/:blogId/posts/ | PostCtrl.getPosts()
POST |  /api/blogs/:blogId/posts/:postId/comments/ | Comments.addComment()
GET   |  /api/blogs/:blogId/posts/:postId/comments/ | Comments.getComments()
...

What I tried (and I wish it could work) so far:
@Controller(`/:postId/comments`)
export class Comments {
  ...
  @Post(`/`)
  public addComment (
    @PathParams('blogId') blogId: string,
    @PathParams('postId') postId: string,
  ) {
    console.log(blogId, postId); // both are undefined
  }
  ...
}

@Controller(`/:blogId/posts`, Comments)
export class PostCtrl {
  ...
}

The problem is that the path parameters defined within the controller base route are not injected to the controller api methods. Any ideas?

Hi @m0uneer,
I found this subject http://stackoverflow.com/questions/28977253/express-router-undefined-params-with-router-use-when-split-across-files.
I add new annotation to configure the Router. So with your example:
@Controller(`/:postId/comments`)
@MergeParams(true)
export class Comments {
  ...
  @Post(`/`)
  public addComment (
    @PathParams('blogId') blogId: string,
    @PathParams('postId') postId: string,
  ) {
    console.log(blogId, postId); // both are undefined
  }
  ...
}

@Controller(`/:blogId/posts`, Comments)
@MergeParams(true)
export class PostCtrl {
  ...
}

Add @MergeParams(true) and that will work fine !
Romain

you need to update ts-express-decorators v1.4.5 ;)

Great, Thanks Romakita :)

Hi Romatika,
V1.4.8:
Error:(3, 76) TS2305:Module '".../node_modules/ts-express-decorators/lib/index"' has no exported member 'MergeParams'.

Hi @m0uneer ,
Sorry for this bug. It's fixed with v1.4.9.
See you

Thanks for your efforts.


REPL ModuleNotFoundError: micropip

I have the following error after trying the REPL on https://elilambnz.github.io/react-py :

On firefox & chrome

I believe this is an issue with the current version of Pyodide that react-py is using.
Despite the error message, functionality of the REPL should be unaffected. You can focus the input by clicking the grey box to the right of >>>. This UI will be improved in the future too.


Battery Life Model Additions & Other Updates

In SSC there are two new battery life models for NMC Graphite https://github.com/NREL/ssc/pull/579 and LMO LTO https://github.com/NREL/ssc/pull/588 chemistries. These should be made available in SAM. Updates to LMO LTO defaults will be needed.
Also, battery thermal defaults for the size of the battery relative to the capacity should be updated for Commercial and utility-scale batteries. The current values are for residential-scale batteries and over-estimate the size of the battery for MW+ systems.

completed in #691


Add tests for functions with lxml type annotations.

Until now there were no tests that checked how mypy handles annotated python code.
This PR adds a few such tests for _Element, _Comment and _ElementTree.
These test rely on pytest-mypy-plugins. Therefore, they are inherently incomplete. Specifically, since the test code is never executed, there is no check that the code is valid. For example, the stubs could define a function that does not exist in lxml and these tests would fail to capture this issue.

@udifuchs I suppose your change is actually fine. The failure comes from most recent pyright detecting a problem with existing lxml.etree stub, which was not catched with previous pyright releases. Will come up with a patch to existing code, and rerun the checks again.


feature: allow minResizeWidth to be set

This PR implements the minResize-Prop which specifies to what minimum width a column can be resized.
I found this issue where @gary-menzel mentions something like this. I found this after I added the functionality.
Please review this PR and suggest changes. As of now the functionality is in place and satisfying my current needs. I would like to see this in the main repo otherwise I will have to use my fork from now on.

Issue with minResizeWidth props. I am unable to set minResizeWidth. It's not working.
It will be great if I get solution. Thanks!

@visshaljagtap As far as I am aware there has not been a new release after this PR got merged. Are you installing react-table from npm? If so and you want to use this new prop then you should install directly from GitHub. But to be honest I would hold of on it until it either gets released or next major version is around the corner. While I did implement the prop in this PR we decided not to use It until a normal release arrives. Maybe you can do the same 👍


Is it a good idea to define the None in the input shape as placeholder ?

Hi, all
We know the first None in the input shape [None, None , 100]   denotes batch size and the second None is timestamp .
Can we create something like [batch_size_placeholder , timestamp_placeholder , 100]  in order to make it easy to understand ?

No, you are wrong. In input_shape=(None,None,100), the 1st None means the number of rows in a 4D tensor, and the 2nd None means the number of columns in a 4D tensor. The batch size is NOT included in input_shape, which actually make sense because a model has to be compatible with an arbitrary batch size that a user selected during training.


bug: regenerate chat does not reuse images

Tested on 4.5
To reproduce:

Send an image and ask "what's that"
click on "regenerate"

Fixed in 4.6


Clone (copy) request

It would be great if I could clone request,
Won't need to write all headers every request and work would be much faster.

@arturwwl  thanks for the feedback. I've been MIA for a while but now i'm back on track so i'll try to resolve most of the issues soon!


Support custom loggers

Fixes #3 by adding an option to pass a custom logger implementation instead of console

Thanks!
https://github.com/fcomb/redux-logger/releases/tag/1.0.2


Unnecessary underline

When I write a simple text line "note", the toXhtml() method always returns a text with  in it, even tho I've put no styling to the content.
example:
note
this
is
a
note

output:
note
this
is
a
note

As is noted on the project home page, this project is discontinued, pending some possible future from-scratch rewrite.


Remove .pyc files

As has been pointed out (tangentially) in a few other threads, I don't think we need to be checking bytecode into the repo. Let's remove .pyc files.

With #107 merged this can be closed now. Closing.