*NEW* USB Input/Output Board -- Fusion Brain - Page 7

2k1Toaster · 04-08-2007, 07:26 PM

Quote: Originally Posted by Ruffy

poop i wasent selected as a beta tester.

POOP I SAY!

Sorry. We only have 6 board coming now to test them out. 1 for me, 1 for Tim, and 4 for betas.

and @ redian: I have no clue what this is:

!

But maybe it can be our mascot!

2k1Toaster · 04-09-2007, 03:44 AM

Ok. I am putting the final "flare"

on the software, and would like some input.

What do you want the software to do based on conditions from the inputs?

Right now button presses to applications, as well as change the state of an output are possible, but what else do you guys want?

The button press pretty much encompasses everything, but I thought I could get some opinions.

Here is your chance to chime in!

h3rk · 04-09-2007, 03:50 AM

Maybe timers. Like time delay relays. If you press a button it will stay on for X seconds or or wont activate for X seconds. outputs are tied to on_click events? What about triggering outputs to activate upon inputs, or combination of input and button, which could be mapped with software.

2k1Toaster · 04-09-2007, 03:51 AM

I should also add, anything special in particular about the software maybe?

As of now it can be skinned, log analoge input data and be externally controlled to put it simply. Of course the skinning includes options from changing the font on the buttons to the images to running hidden in the system tray.

So suggestions?

P3D4T0R · 04-09-2007, 03:53 AM

Open source? A way to hack the firmware?

h3rk · 04-09-2007, 03:57 AM

Trigger-able (alarm-like) events based on analog setpoint levels. For example, if battery voltage is low it could start the vehicle and recharge for either a prescribed time or voltage, assuming other prerequisites are met. Something that would allow a user to set something like that (or similar process) up. It'd be nice if the hardware had a wake-on-lan output for that however.

But that takes some smarts (PIC-smarts, not badger smarts) Is there a controller?

2k1Toaster · 04-09-2007, 04:02 AM

Quote: Originally Posted by h3rk

Maybe timers. Like time delay relays.

Done. You can make it an "animation" with only 1 frame which would be on, and then have that frame repeat x amount of times. Each frame/iteration takes t seconds. t is user settable variable between 250ms and 1s which is the update frequency of the PIC. So if you want it on for 10 seconds then set 10/t is the number of iterations needed.

Is this too complicated for people? I figured it would be very easy once people understand it...

Quote: Originally Posted by h3rk

If you press a button it will stay on for X seconds or or wont activate for X seconds.

You mean the digital input is fooled into thinking that the button is being pressed for x seconds when it is really only being pressed momentarily? This could cause havoc in my eyes. Why out of curiosity?

Quote: Originally Posted by h3rk

outputs are tied to on_click events?

Not sure what you mean. Of course when you push the button for the digital output an onclick event is triggered and it changes the output next refresh cycle (250ms to 1s).

Quote: Originally Posted by h3rk

What about triggering outputs to activate upon inputs

The temperature, photocell, and potentiometer can all do this. I dont see a need for the accelerometer other than to flash "Slow the F down crazy man" after like 10g's.

Quote: Originally Posted by h3rk

or combination of input and button, which could be mapped with software.

Interesting... Definately implementable... What would the benefit of this be though? That would mean a button only works if the analog input is within specs... So no volume control while the accelerometer reads more than x g's? I dunno.

Good ideas. And I am not critisizing, I just want to see where the ideas lead. I am always interested in ideas!

Quote: Originally Posted by P3D4T0R

Open source? A way to hack the firmware?

It will be open source.

Hack the firmware? If you want, we shall add!

But everything is done software side which is completely open source once we get it up and running.

Quote: Originally Posted by h3rk

Trigger-able (alarm-like) events based on analog setpoint levels. For example, if battery voltage is low it could start the vehicle and recharge for either a prescribed time or voltage, assuming other prerequisites are met. Something that would allow a user to set something like that (or similar process) up. It'd be nice if the hardware had a wake-on-lan output for that however.

the PC must be on in order for the device to function. That way you dont have to shut it down when you leave. Neither of these are doable in the way you might want.

If the PC is on, car is off, then yes it could theoretically start the car, but the PC will drain the battery by being on, so sort of a viscious circle!

And the PIC makes no descisions such as interpretting a WOL signal. It only gets and sets the inputs and outputs and sends it to the PC to figure out. Sorry.

h3rk · 04-09-2007, 04:20 AM

Quote: Originally Posted by 2k1Toaster

Done. You can make it an "animation" with only 1 frame which would be on, and then have that frame repeat x amount of times. Each frame/iteration takes t seconds. t is user settable variable between 250ms and 1s which is the update frequency of the PIC. So if you want it on for 10 seconds then set 10/t is the number of iterations needed.

Is this too complicated for people? I figured it would be very easy once people understand it...

Right on!

Quote: Originally Posted by 2k1Toaster

You mean the digital input is fooled into thinking that the button is being pressed for x seconds when it is really only being pressed momentarily? This could cause havoc in my eyes. Why out of curiosity?

If the 'tied' output turns on with one press. The timer would cause it to turn off after set time. Possible use would be an actuator. It would prevent someone from having to use limit switches on their rocker-panel rocket launchers.

Quote: Originally Posted by 2k1Toaster

The temperature, photocell, and potentiometer can all do this. I dont see a need for the accelerometer other than to flash "Slow the F down crazy man" after like 10g's.

Sweet.

Quote: Originally Posted by 2k1Toaster

Interesting... Definately implementable... What would the benefit of this be though? That would mean a button only works if the analog input is within specs... So no volume control while the accelerometer reads more than x g's? I dunno.

Safety interlocks. "you cant do this because you're not going Fast Enough" would be more my taste.

Quote: Originally Posted by 2k1Toaster

Good ideas. And I am not critisizing, I just want to see where the ideas lead. I am always interested in ideas!

All of my ideas can't be top-notch, but I have my moments. But I think you may know I'm not advertising all of them...yet. But you get to the good ones by blurting out all of the bad ones and getting them outta the way.

Quote: Originally Posted by 2k1Toaster

the PC must be on in order for the device to function. That way you dont have to shut it down when you leave. Neither of these are doable in the way you might want.

If the PC is on, car is off, then yes it could theoretically start the car, but the PC will drain the battery by being on, so sort of a viscious circle!

And the PIC makes no descisions such as

..I was thinking more like sending...

Quote: Originally Posted by 2k1Toaster

interpretting a WOL signal. It only gets and sets the inputs and outputs and sends it to the PC to figure out. Sorry.

But I understand, making smart I/O's with universal use in mind isn't the same.

Oh and by the way I'd like to reserve a place in line for when they become available to the rest of us, if I may.

P3D4T0R · 04-09-2007, 05:55 AM

Quote: Originally Posted by 2k1Toaster

It will be open source.
Hack the firmware? If you want, we shall add!

Sweet... Thank you.

I was wondering for the outputs if there could be a "save state" and/or "default state" option. What I mean is when the computer is powered off the board will keep whatever state it was in but also be able to return to its default state if wanted. I dont know if that made sense, if it didn't ill fix it later.

h3rk · 04-09-2007, 06:11 AM

I like that idea. The each output could have two attributes like:
.state.default=1
.state.last=0

speedy_parker · 04-09-2007, 08:42 AM

from h3rk:
Oh and by the way I'd like to reserve a place in line for when they become available to the rest of us, if I may.

This is looking great! Thanks for all the work guys.

greenman100 · 04-09-2007, 08:45 AM

Quote: Originally Posted by h3rk

I like that idea. The each output could have two attributes like:
.state.default=1
.state.last=0

Already implemented.

h3rk · 04-09-2007, 08:45 AM

Quote: Originally Posted by speedy_parker

from h3rk:
Oh and by the way I'd like to reserve a place in line for when they become available to the rest of us, if I may.

This is looking great! Thanks for all the work guys.

Oh great, someone must have caught me out on the town, in drag, and now thinks I'm a she.

Dammit, it was just one night

greenman100 · 04-09-2007, 09:49 AM

Quote: Originally Posted by speedy_parker

from h3rk:
Oh and by the way I'd like to reserve a place in line for when they become available to the rest of us, if I may.

There will be 100 available immediately. There is no need for worry as to stock.

2k1Toaster · 04-09-2007, 11:12 AM

Quote: Originally Posted by h3rk

Right on!

Quote: Originally Posted by h3rk

If the 'tied' output turns on with one press. The timer would cause it to turn off after set time. Possible use would be an actuator. It would prevent someone from having to use limit switches on their rocker-panel rocket launchers.

Already done!

Quote: Originally Posted by h3rk

All of my ideas can't be top-notch, but I have my moments. But I think you may know I'm not advertising all of them...yet. But you get to the good ones by blurting out all of the bad ones and getting them outta the way.

Keep them coming!

Quote: Originally Posted by P3D4T0R

Sweet... Thank you.

I was wondering for the outputs if there could be a "save state" and/or "default state" option. What I mean is when the computer is powered off the board will keep whatever state it was in but also be able to return to its default state if wanted. I dont know if that made sense, if it didn't ill fix it later.

Quote: Originally Posted by h3rk

I like that idea. The each output could have two attributes like:
.state.default=1
.state.last=0

done.

Not the last state, but default state is saved as can be referred to by pushing the big 'ol default button on the screen. It is also the state that is loaded when the app starts. So if you want your lights on when the board comes on, but not your 3gillion dB bullhorn, you can set that.

Quote: Originally Posted by greenman100

Already implemented.

You beat me to it!