Open Source Bitfenix Recon Software (Linux, OSX, Windows) (Beta Testers)

[n3mss]

Hi,

If you have a BitFenix Recon (fan controller) and would like to beta test some open source software for controlling it, then you might be able to lend a hand

Phoebetria:
https://sourceforge.net/projects/phoebetria/

Current status of the software (developed independently and not in association with or endorsed by BitFenix) is beta, meaning that we're really after people willing to test it. The binary files (for OSX, Fedora 17, and Windows) on the site will be updated this weekend, but the update will include very few user visible changes.

All of the features of the OEM software are currently supported, except for web control of the controller. Features that exceed the OEM software are definitely planned once the current release (and the imminent release this weekend) are tested and feedback received from the community (of course we have our own ideas of extended features, but maybe there is something *you* want that we haven't thought of).

The changes for the new binaries, when they are released, are mostly behind the scenes and will no doubt introduce new bugs BUT feedback on the current V1.0.0-Beta release are still very welcome.

Also, if you can help in any way please contact us! E.g. packaging/testing for Ubuntu or Mint or Distro-X; translation (localisation); ideas; anything.

Cheers
Craig

 

[n3mss]

Thanks Tealc. I think that the bugs you describe have been fixed.

The "Fan Controller Service" should be turned off. Which reminds me, I should add some code to try and see if it's running or not and ask the user to turn it off (or get the s/ware to turn it off after asking).

The temperature warning thing in the latest version start at "blank" (i.e. they show nothing), so I think that might be fixed (not 100% sure though, I will have to check... that's pretty sad considering it's my code, but yeah I do work full time as well [not as a programmer] and have been doing this for the last 3-4 weeks after work).

I do think that both of the bugs you describe are fixed, but cannot be sure There is just me and one other person at the moment and your feedback is the first!

What I might do is re-read your message tomorrow and re-check where things are at now, after that Windows Executable was released. There have been a LOT of behind the scenes changes.

If you're willing I'll send you a compiled snapshot of the latest version to test tomorrow (I am in Australia, so I guess tomorrow might be very late tonight for you).

Cheers

PS I might add some more debugging output so bugs are easier to find. Currently I test it on Windows 7 and Fedora 17 (64), and another contributor compiles and tests it on OSX Lion.

 

[n3mss]

You probably already know this but your channel numbers on the temperature warning thing start at 0 rather than 1, so it's a bit confusing when you pull up the dialog and it gives you a different number.

Doh!

I see what you mean now Yes I'll fix that. Thank you!

Also, I think user naming of channels are a given (e.g. instead of "channel 0" the user may call it "front intake"). This won't happen in the next release but it's hight on the list.

Edit: see I still called it "channel 0" in my response to you. LOL. Yeah, it will be fixed and I really had no idea I was doing that.

 

[n3mss]

Ok thanks!, just trying to work out how to get the snapshot to you. I think what I'll do is upload it to the sourceforge site so you know it can be trusted; I'll just have to check some things first.

Edit: After the next release I'll probably put together a list of Beta Testers. Since you've found at least one bug (the channel numbering) you're on the list.

 

[n3mss]

Ok, I've uploaded the latest build (Windows only) to: http://sourceforge.net/projects/pho...etria_PRE_RELEASE_1.0.1_20120830.zip/download

Note that this isn't a release... it's as things stand right at this moment There are not many user-visible changes but there are a lot of changes behind the scenes (code is cleaner and more efficient). Basically the idea behind providing this file is to see if bugs like the one quoted below are fixed (in other words it's better that I don't try to hunt down bugs that have already been fixed during the large behind-the-scene changes)

Not sure if it's my setup but after a while the program starts to ignore any input I make. Now every time I open it I can't drag the sliders, despite it being in manual control. I did open the normal recon service while fiddling about so it might be that that has taken control away from me. I also noticed that changes I was making to the temperature warning were sometimes being ignored. Again this could be an issue from opening the recon service.

^^^ I am particularly interested in this.

Phoebetria _should_ work with the Bitfenix service running in the background, but I don't really recommend it.

Cheers
Craig

 

[n3mss]

Will give it a go Craig.

Cheers. Minimise to tray is probably the biggest user-visible change

 

[n3mss]

Just a quick question, do you think it will ever be possible for the fan speed to be adjusted based on temperatures of CPU / GPU?

It's something we (myself and the other developer) have talked about (apart from him using OSX I think his other motivation for joining Phoebetria was in the hope that it would one day do exactly what you ask). Certainly it would be a very nice thing to be able to do.

Short answer. yes, it's _possible_ (by adding the code to Phoebetria; i.e. you couldn't do it using the Recon without software loaded).

Long answer. First, a disclosure: I don't know how to read the temperatures from the CPU or GPU. Therefore we'd need a developer with knowledge about this. I'm not ruling it out though.

I've very quickly looked at the source code for projects such as Open Hardware Monitor. Three approaches immediately come to mind: (a) incorporating cpu/gpu temp monitoring code into Phoebetria; (b) running a second app (like Open Hardware Monitor [OHM]) that logs to a file and Phoebetria reads the log entries; and (c) maybe adding interprocess communication to a project such as OHM. Any of these three solutions (and there are other ideas as well) would work. In theory. On Windows only. Idea (a) could probably be made to work on OS X and Linux as well although I haven't looked into how that would specifically be done. The main thing that I want is that Phoebetria remains cross-platform and that features are identical on each platform (even if the way the feature is provided is different).

TLDR: Yes, it's possible and it's being thought about. It won't be in the next release or two unless our current situation changes


Edit: Option (a) "Incorporating CPU/GPU monitoring code directly in Phoebetria" is in my mind the best solution. But I have a sinking feeling that it would be a mammoth undertaking.

 

[n3mss]

Thanks very much for the detailed response, Tealc!

I think you're right about the RPM anomaly being in the Recon itself. Phoebetria just reads the RPM reported by the Recon (no calculations are done on the result) and outputs them, so..

Do you like the balloon message (I had no idea what to write, LOL)? I'll be adding tooltips to the balloon message so you can just hover the mouse over the icon and get a status summary.

As for the BitFenix software running at the same time... If I do that (and I do it less and less now) I find that if I open the service AND the web interface before Phoebetria they both work better together (I think Phoebetria must put a lock on the USB when it connects, but I can't work out how to stop that).

Cheers


Edit: In the version I compiled for you the slider tooltips do not update correctly; I fixed that issue yesterday afternoon

 

[n3mss]

I'm not a big fan off balloon tips to be honest. Is there a way to stop the behaviour and have it just happen once per application run, or first time, or have it as a user option to turn the balloon off.

Yes, I can turn it off. Or make it a user preference. I appreciate the feedback! (I actually don't like them myself, either)

I've come back to it this evening and the application isn't as responsive as this morning. It could be that my PC went to sleep and broke the application's strange hold on the USB. The sliders immediately snap to the previous position and after a few seconds come to the point I selected. This morning, before running the fan controller service alongside, they waited a few seconds. This could be that Recon has accepted the signal faster or something. I don't know how the application works regarding those graphical type updates.

It's difficut, but I think I know what you mean. The problem (I think, if I am understanding you correctly) is that the recon only accepts one command every 110ms (best case; Phoebetria uses 200ms when sending requests) and you have to send a request for each channel to get its status; i.e. it takes 1 second to send the requests for channel status. Then you have to wait for the responses This gives a feeling of "lag". I'll keep trying to think of ways to at least give the illusion of it being more responsive.

I wonder if after sleeping the Recon itself does something different as well (like a startup/recalibration/something)? I might do some experiments.

Edit: getting the "alarm temp" for each channel is a different request than getting the channel RPM, so this adds another 5 requests to do.


Question: Was Phoebetria running when the computer entered sleep?

 

[n3mss]

It's not a big thing but due to the delay of Recon actually adjusting speed (5-10 seconds) sometimes you think it hasn't received the command so go over it again. I prefer it to acknowledge the setting change by staying there for a few seconds, or even stay there and adjust the RPM visally and not the slider. Sliders should really stay where you drag them to and not bounce up and down and again I know the Recon software does this.

Ah, I understand. Thanks. I will add a delay or your other suggestion (which is probably better) after setting a manual value where the slider doesn't update.

 

[n3mss]

Ok, I am going with your suggestion, Tealc.

Current version when in manual mode now keeps the sliders at the position the user sets them to; only the text box RPM is changed (when the RPM is not at the manually set position). I need to test it quite a bit yet, but it does seem to be working. The main reason I'd like to do a fair bit of testing is because I updated a LOT of code to do this so the GUI responds differently when you change a setting. It's better now. Thanks

Edit: I just "got" your username. Nice one.

Edit 2: Contact me through sourceforge if you want a different name (from tealc) added to the thanks file I am going to create. The thanks files will probably go in the about dialog as well.

 

[n3mss]

Had a funny thing just happen with the manual control. If you hammer manual On/Off for a bit (3 or 4 times) you lose actual manual control until you toggle it slowly and nicely.

That's a feature... not a bug

 

[n3mss]

We'll be releasing version 1.1.1 this weekend.

Tealc, I've implemented the feature where the channel speed sliders are "locked" after you manually set them. They still may change once after setting a manual speed if a packet comes from the device saying a different manual speed. This is very difficult to avoid because there is no way to tell if the packet coming from the device is the result of an earlier request or the user manually changing the manual RPM using the Recon panel. Version 1.2.x will have a separate dial for setting the manual RPM and the sliders will become "progress bars".

Cheers,
Craig

 

[n3mss]

Sneak peak:

The little lights under the RPM sliders change to yellow if the manually set RPM does not match the current RPM (instead of the sliders moving around the place until they settle, when in manual mode.)

Release will be this weekend.

After this release we will start working on features that the OEM software does not provide. E.g. Software fan curves

 

[n3mss]

Version 1.1.1 (Beta) is released!

https://sourceforge.net/projects/phoebetria/

Although this is a "point release" many changes and improvements have
been incorporated. Behind the scenes the code is more efficient. These
efficiency gains mean that, from a user perspective, the GUI is more
responsive and many bugs have been fixed. The GUI has been polished and
now the controls and window properly resize themselves depending on user
settings and the user environment. Additionally, when setting a manual
RPM using the RPM sliders, the sliders now 'lock' to the user-defined
RPM; if the reported RPM is not equivalent to the manual RPM an
indicator below the slider changes to yellow. Minimise to tray has been
implemented and user profiles have been improved.

This release is also a milestone. From this point onward we will be
adding features to Phoebetria that the OEM software does not provide.

 

[n3mss]

Thanks Tealc

Two questions:

a) What fans (brand, model number); I'll try and order them (if they're available in Australia)
b) How are you getting the actual RPM of each of the fans? At the moment the best I can do is read voltage using a multimeter, but if there's a better way I'll do that

Cheers
Craig

 

[n3mss]

Will definatly be giving this a test when i get my recon soon. Is there any plans to attempt to get the remote web access feature working in this version or is that far too complex to try to reverse engineer?

There are plans to add the feature. I am not exactly sure of an ETA because Chris (the other developer) will probably be looking after that side of things. At the moment, though, it's not #1 on the list of things to do, but we are open to persuasion

Edit: My biggest concern about the "remote web access" is how to implement it in a secure manner. It'll take some thought...

 

[n3mss]

Hope this ^^ helps.

I believe speedfan's reading is reasonably accurate but don't have anything to actually check it with, although I was going to build a circuit to do it a while back.

Thanks Tealc. I'll buy one of those fans and try and hook up a wire to the m/b so I have a similar set up.

Is the bfx fan service turned off when you ran the tests? Some internal changes to Phoebetria may mean that it now conflicts.

Thanks a lot for the reply. It would be a cool feature to have, thats one of the main selling points of this controller IMO.

I will definatly be giving this software a run though, especially as it develops features that the official software lacks, cant wait to see what you have in mind!

Thank *you*.

 

[n3mss]

Ok, I have been testing with two Noctua NF-S12B but cannot replicate. I might have to add the fan speed monitor wire and run it to a m/b header so I can see if maybe there is interference from doing that.

 

[n3mss]

Hi scorpuk... did you add the rule to /etc/udev/rules.d/ and add you user to the fancontrollers group?

I've noticed that on Fedora I couldn't get udev to recognise the new rule no matter what I tried; I ended up having to reboot :/

99-fancontroller.rules

SUBSYSTEM=="usb", ATTRS{idVendor}=="0c45", ATTRS{idProduct}=="7100", NAME="bfxrecon", GROUP="fancontrollers"

If that doesn't work, please sudo lsusb and email me the output and I'll see if I can see anything (craigrobbins at users.sf.net)

Cheers