I recently got my hands on a used Sofirn SP36 Anduril and found that the temperature limit is exceeded by more than 10 K, although the measured temperature is relatively accurate. This made me curious, especially since I recently ordered some Emisar D4V2s. So I wrote a little simulation to test the thermal regulation code.
There is a lot of magic involved to prevent the current thermal regulation from exploding, I think there is need for another rewrite. I'll probably give it a try once my D4V2 arrives.
PS: On an aside, the project name (sphagetti-monster) hits the nail on the head. :D
I am even too stupid to get that Bazaar to open your trunk, the plenty URLs I tried do not work
Anduril does not work properly with temp reading
the Wiki gets it for granted you know which link and how to add and don’t even give any examples
with https://
I downloaded every single file to my PC manually and replaced the old ones, its still reading garbage then it seems to read correctly after running it a while
but testing the driver with heat applied does not adjust output at all
You’re using a website that presents the repository rather than the repository.
The website shows that you should use “bzr branch lp:~toykeeper/flashlight-firmware/fsm” command.
With your UI you may try to enter “lp:~toykeeper/flashlight-firmware/fsm” URL.
Those people who write this bazaar wiki seem to think everyone is an expert programmer and know all the basics
with your link I get this error
Please
all I am asking is a zip or similar container with a working Anduril build for AS7
.
I am wasting again now almost 4 hours on this and can’t build drivers in that time for the community and I have not much time at all right now for weeks and its not looking better this year
I am close to quit Anduril with a March build like I did with NarsilM v1.2 and support no newer versions anymore
Add -fwhole-program to the CFLAGS in build.sh, and comment out #define USE_VERSION_CHECK from anduril.c (or USE_BIKE_FLASHER_MODE or another mode if you really need the version check)
disable 2 strobe modes works as well 99.7% full now
I got absolutely no idea how to do that, that file is not even on the dependencies list in my project
This is the code when open in my Editor
I use a simple build “Anduril” project button with my mouse
I use no scripts or make file or other stuff the programmers are always talking of to build 20 versions at once with different settings in them
My bad, I should have realized using Atmel Studio doesn’t use that build.sh. You might be able to get back some space by adding the -fwhole-program flag to the miscellaneous flags here:
But I haven’t tried it. I’m not set up to compile for AVR.
Right click on the project in the solution explorer at the right, and choose Properties, to find the menu I showed. Then add the -fwhole-program to that huge list of flags in Miscellaneous (or maybe to the shorter list in Optimization). The flags are separated by spaces, and are what get passed to the compiler I use on the command line instead.
If it still gives you trouble, and you’re willing to wait a few days, I can try to set up Atmel Studio for AVR myself and give it a try.
Oh, er, the “ramping-ui” firmware was never shipped on the D4. I think you’re probably looking for RampingIOS. V2 is under the Tom_E directory, and V3 is in the spaghetti-monster directory.
It’s configured in cfg-mateminco-mf01-mini.h, but it’s in the fsm branch along with all the other recent development. The trunk branch is only updated occasionally.
That’s really interesting. I’ve heard a couple other reports of similar things too. I didn’t make a D1 tiny1634 build target, so it’s probably using a D4 V2 driver.
That should work okay, I suppose. Not much is different between the two configurations. But the thermal regulation might act a little weird, pulling the output down faster than necessary. I haven’t tried a D4 V2 firmware build in a D1, so I’m not sure if the thermal response is okay.
Hi, sorry about that. I forgot to add the FETless FW3A build target…
… until you reminded me just now.
It’s now included in the repository as cfg-fw3a-nofet.h.
Pretty much, yes. It needs to be in its native build environment unless you really know what you’re doing.
To set that up in Windows, step 1 is to install WSL. Either the Debian flavor or Ubuntu flavor should work.
From there, it’s mostly a matter of following the README in the code repository. There are a few commands to run to install other tools, and then the “make” tool should work.
Technically, it can be compiled in Atmel Studio, but it’s not easy and, as shown earlier on this page, people run into a lot of problems trying to do it that way. It’s not supported or recommended, and is an easy way to get headaches or bugs.