E-switch UI Development / FSM

@SammysHP I can design and hand populate pcb’s and I can’t do it.
Just sayin. I even have a Linux machine and STILL can’t use bzr / all that crazy stuff that I just can’t mentally follow, all these command lines look like jibberish to me. I don’t even know where the terminal is! So now without AS7 on my windows machine working apparently I can no longer build FW at all (and am thus limited to precompiled hexes, bummer).

There are HW guys and there are SW guys and some people just can’t learn…

Still working on getting AS7 working with modern FSM, down to 11 errors, 5 warnings and a message!

Remember when Mattaus taught us all how to use eagle? Anyone wanna do that for a Linux based build environment on windows? I mean complete start to finish, no NOTHING to being able to do it…

The terminal commands are really pretty simple if you just accept that you don’t care what they mean and simply copy/paste the ones TK says. I started using computers back in the DOS days so I have a pretty good handle on how a command line works, just not the exact commands for linux.

It would be cool if TK included that linux setup guide in the OP (make is easier for me to find if I needed it again). Basically all the commands to go from a fresh linux install to compiling the firmware. She already had most of the commands in the post I used, just some bzr commands that I had to look up myself IIRC.

Once all of those commands are run, then it is simply a matter of using a text editor you like (I use Atom personally) and editing the firmware like normal.

Then you simply run the compile scripts that TK includes and things just seem to work.

I am also more comfortable using windows but I have had much less issues compiling on linux. Once those commands that you can copy/paste are out of the way, it is really not that different then using windows since atom has a full GUI (I use Atom on windows as well).

Another advantage of using a virtual machine for compiling is that I can save the state with all the firmware windows I want open and ready for editing. Makes it easier to jump in and out of edits over time.

TK, from the 3 changes that I proposed for merge you took only 1. That’s OK but I’d like to know whether to bother you with similar changes (ones that don’t affect any default config) in the future.

Sorry, I still had the tab open, but I hadn’t gotten to it yet. The other two changes both needed fixes before they could be added, so I put it off until later. It’s unfortunately easy to let “later” be a long time though, when one has hundreds of windows and tabs open, all waiting for attention.

Anyway, I applied the necessary fixes and added the changes for making beacon mode and momentary mode optional.

I see. There’s no need to rush such changes, I just wanted to know where I stood.
I have a couple of similar changes:
https://code.launchpad.net/~nisjuk/flashlight-firmware/nisjuk2
(note: it’s a different branch) revisions 463, 464

Am I doing it right? I’d like to validate before I fire the command…

First I read the fuse values:
avrdude -c usbasp -p t1634 -P COM3 -b 19200 -v
(…)
Fuses OK (E:FF, H:DE, L:E2)

In the datasheet I see that EESAVE is bit 3 of high fuse.
Decoding the fuse (just to check if I understand things right) I get:

  • Bit 0 (BODLEVEL0)
  • Bit 5 (SPIEN)

So to set the bit 3 I should provide avrdude with the following argument:
-U hfuse:w:0xd6:m

Right?

Yes, your command should be correct.

Btw: This fuse calculator is a big help, but always verify with the datasheet. AVR® Fuse Calculator – The Engbedded Blog

Thanks. Actually I used it to do binary calculation but needed to consult the ds because the calculator doesn’t support 1634.

I have one improvement idea….I’m not sure whether it can be done with software alone or whether it requires special hardware but I’m sure you TK know. :wink:

The aux LEDs when running low are not very visible during the day.
At the same time they are brighter than moonlight and actually disturbingly bright during the night.

Maybe it would be possible to detect ambient lighting conditions with the main LEDs and adjust aux brightness accordingly?

It requires special hardware. No supported drivers have this capability. Even the FW3A’s optic nerve can’t determine ambient light levels, since its signal is highpassed to pull it down to zero.

However, one question. Did you mean to say “The aux LEDs when running high”? Because on low, they’re usually nowhere near the brightness of moon mode.

No, I meant low. I’ll re-check that this night because maybe they were not running at the level I thought they were…

Another small fix in changeset 472.
BTW, what gcc version do you use?
I use 9.2 and a few images don’t build:

Another e-switch: https://www.washingtonpost.com/nation/2019/12/05/miguel-wattson-electric-eel-tennessee-christmas-lights-twitter/

This link leads to a paywall. They want me to pay either with cash or privacy and don’t serve content unless I do.

I checked that:
It’s very likely that I actually used high.
That said, the lows could really see some improvement.
The different colours have very different brightness. Blue is less bright than moonlight but nevertheless disturbingly bright at some angles.
Green seems slightly dimmer to my eyes and red is much much dimmer. White is not white, red component is completely invisible…

I’ll try to improve this. Sounds like a good noob task. :slight_smile:

ADDED:

If I understand that correctly - this is controlled purely by hardware, not by software. :frowning:

I thought that picking the best compiler version would be a possibility to save a few bytes.
So I tried gcc 6,7,8,9 to check which produces the smallest output.
gcc 8 won.
But it still can’t compile these 2 configs which makes me thing that TK may be using something even older than that…

Try with gcc-avr 5.4, maybe then it works.

I’m not sure this is the right place to ask, but will files for the Astrolux HL01 eventually be added to the /torches/fsm/ download list? I’m not yet sure how to hook up that light for flashing, but I’m sure it can be done. And I always get a kick out of upgrading. :slight_smile:

That probably depends on whether Astrolux gives me a copy of the source code they used.

It’s one of like a dozen apparent license violations I’ve been meaning to chase down…

With the new Haikelite HK04 (quad XKP50.2) on VTC6D cells and spring bypasses, the max of 70C doesn't give me 30 secs, best I can get is ~22 secs. I need a bit more headroom. Sure would have been nice to know this 70C max limit - I've been clicking 50 times, 60 times, 70 times over and over again - no idea, til i came across this thread and this post in this other thread: https://budgetlightforum.com/t/-/54947/161.

Could you please at least update the latest Anduril manual in the repository with this limit? That should be the ultimate ref. I re-read a "few" of the hard copy Anduril manuals I got and couldn't find it.

Btw, I don't see any config file in the repository for the HK04 - is HL doing this stuff on their own? Funny - their website doesn't exist anymore, or is temporarily down, dunno - used to be Haikelite.top.

Update: forgot to mention it's a quad XHP50.2, measured 37 amps at a min on full turbo (before spring bypasses added), does about 15,000 lumens at start and is the size of a SP36, so yes, it does get hot. Maybe even a max of 80C would be fine.