Milovana.com

seraph0x wrote:Hey,

I just added you to the Beta Tester group so you can access the preview release for Nyx, the FlashTease editor. Check it out here.

(Nothing on the scripting language yet though, that is mostly being discussed in the Milovana Team forum.)

Feel free to post feedback in the thread above, but don't feel any obligation, I just thought you might want to take a look.

Now, I leave it up to you how we are going to proceed. As I see it there are two main options:

- You start your project independently and we use PMs or email to talk about the interface, basically with me as a representative of Milovana and you as a representative of your project.

- Or you join the Milovana Team and become our official chief of hardware technology. We would then discuss the standard in our Team Forum and release the client as an official Milovana product under your lead.

Both options are in my eyes perfectly viable and not too far apart. The second one stresses a closer cooperation and the first one stresses your project's independence. I really don't care too much, maybe a slight preference for option two, but I want to leave it up to you.

Let me know what you think!

Cheers,

Seraph0x

nilcum wrote:

seraph0x wrote:Hey,

I just added you to the Beta Tester group so you can access the preview release for Nyx, the FlashTease editor. Check it out here.

Wow that editor looks GREAT! There was obviously a lot of time and hard work put into it. Good on ya!!!

- You start your project independently and we use PMs or email to talk about the interface, basically with me as a representative of Milovana and you as a representative of your project.

- Or you join the Milovana Team and become our official chief of hardware technology. We would then discuss the standard in our Team Forum and release the client as an official Milovana product under your lead.

I'd rather go with option two. I think it would be easier to get others involved if there is a direct association with Milovana. However, I feel very strongly that whatever is developed be decoupled from any specific program or system. Meaning, there will be a well defined interface for both software and hardware interop but that interface will be available for anyone to use with any system. I think we are on the same page with this but I wanted to make sure.

Now that we have that laid out lets talk some tech.

I really like your idea of using HTTP on a local port for this. I think it fits this problem perfectly. I'm planning to write the initial daemon over the next couple days. Do you have a preference on a development language. I am very good in Python and C but should be able to use whatever... so long as it will have good support for serial communications.

Which brings me to the next thing. For most of the hardware control I was planning to use a serial device. I can use one that automatically does USB but that makes the initial cost of the hardware slightly more expensive. There are also bluetooth implementations that do the same thing in a black box type of format... but then the cost goes up to about $50 just to get the wireless going. I can look for cheaper options if you feel strongly about bluetooth. For now, I think USB is the way to go.

Next, when starting any hardware project the first thing to address is power. The USB port provides 3v automatically. We can use a cable that pulls power from 2 and get 6v power right off the USB port. This will be fine for a small shock or maybe even an electromagnet but when you start getting into the motorized side of things we are going to need a motor that can move a decent load and I think that it will need more than what the USB port can offer. So, I'm thinking external power supply as a standard design.

The next design choice is how to break things out. I was planning to do Computer -> Control Unit -> Several modules (likely 4 to start with). Each module would have a standard pyhsical interface. Likely a stereo input. The modules would all implement a basic set of command: On, Off, and Level. I want to flush these out a little bit more. One problem I can see right away is that the modules can't provide any feedback to the control unit. This is not a problem for the simple devices but I could see things getting more advanced... such has a hand attached accelerometer that would count the number of strokes and the strength of each one. As you can see I haven't quite worked out all the details yet.

The microcontroller I am thinking of using is the from Atmel's. The ATMega168 is basically an 8-Bit Processor. You get 16K of program space and 23 I/O lines. It will runs at about 20MHz. Best part is the cost $5.00 per unit. That may change if I think we need a beefier chip. The ARM stuff is generally more powerful, but also more expensive, and MUCH more difficult to deal with. There is an open source project called Arduino that uses this microcontroller that I think we would do well to base this stuff off of.

Also, there is no reason to limit the daemon to only controlling hardware. It could very easily do other jobs like peer-to-peer networking and control, text-to-speech, microphone and webcam interactions (though flash also offers this), automatic-updates, anything else you can think of that would be a pain to do in flash or a browser?

Anyway, I know that was a long response. It was kind of a brain dump. For the short term, I want to iron out what the daemon should do, the language of choice, and implement a basic architecture and some of the simple feature.

thanks

seraph0x wrote:

nilcum wrote:Wow that editor looks GREAT! There was obviously a lot of time and hard work put into it. Good on ya!!!

Thanks!

nilcum wrote:I'd rather go with option two. I think it would be easier to get others involved if there is a direct association with Milovana. However, I feel very strongly that whatever is developed be decoupled from any specific program or system. Meaning, there will be a well defined interface for both software and hardware interop but that interface will be available for anyone to use with any system. I think we are on the same page with this but I wanted to make sure.

Exactly. We are absolutely on the same page. If the software doesn't run as smoothly as expected or someone else comes up with a better/different one, we don't want to reprogram the integration. That's why we're interested in a good interface. Also, we want to see the interface being established as an industry standard, a goal for which openness is paramount. In a market niche as small as ours there is no room for cannibalism. We either work together or we all suffer.

Seeing that we 100% agree on both conditions, I'll put up a vote on admitting you to the Team. These votes run three days and I'll let you know about the outcome then.

nilcum wrote:Now that we have that laid out lets talk some tech.

I really like your idea of using HTTP on a local port for this. I think it fits this problem perfectly. I'm planning to write the initial daemon over the next couple days. Do you have a preference on a development language. I am very good in Python and C but should be able to use whatever... so long as it will have good support for serial communications.

It's your decision. Cross-platform compatibility normally would be important to me, but since the interface is open, we can always write a Mac version of the client further down the road. Speed and "niceness" of the client would be more important. Users should not have any disadvantages from installing it and it should take as little resources as possible. I think C/C++ might fit the bill best. Not so sure about .NET. I associate it with buggy, amateurish and slow programs for which you first need to download a huge .NET runtime library which then screws up your already crappy Windows OS. But you know, I might be biased a *little*.

Seriously though, I leave it up to you. I've laid out our interest: We want a nice little program that does as little as necessary, runs fast, doesn't bug people, has few prerequisites, an easy installation and Just Works. Use whatever technology you would use to achieve these goals.

nilcum wrote:Which brings me to the next thing. For most of the hardware control I was planning to use a serial device. I can use one that automatically does USB but that makes the initial cost of the hardware slightly more expensive. There are also bluetooth implementations that do the same thing in a black box type of format... but then the cost goes up to about $50 just to get the wireless going. I can look for cheaper options if you feel strongly about bluetooth. For now, I think USB is the way to go.

Next, when starting any hardware project the first thing to address is power. The USB port provides 3v automatically. We can use a cable that pulls power from 2 and get 6v power right off the USB port. This will be fine for a small shock or maybe even an electromagnet but when you start getting into the motorized side of things we are going to need a motor that can move a decent load and I think that it will need more than what the USB port can offer. So, I'm thinking external power supply as a standard design.

I'm definitely not for Bluetooth and I agree about the advantages of USB.

One piece of advice I can give though is: Make a plan where the first payout is as early as possible. In our case that would probably mean using some USB vibrator that is already being produced in the Teledildonics scene and getting it to run with the client. Then we can get it to run with the FlashTease viewer, release it and check user reaction. If we manage to get that far, then we can think about the next step. It's just: If we start out too ambitious right away, there is a much higher risk we will never get anything done.

nilcum wrote:The next design choice is how to break things out. I was planning to do Computer -> Control Unit -> Several modules (likely 4 to start with). Each module would have a standard pyhsical interface. Likely a stereo input. The modules would all implement a basic set of command: On, Off, and Level. I want to flush these out a little bit more. One problem I can see right away is that the modules can't provide any feedback to the control unit. This is not a problem for the simple devices but I could see things getting more advanced... such has a hand attached accelerometer that would count the number of strokes and the strength of each one. As you can see I haven't quite worked out all the details yet.

Normally you would have some input and some output channels. It's very hard to do a interface that is flexible enough. I think you would at least need one form of input from each device, if only to confirm it's identity. You don't want the TENS unit electrocuting you, because you plugged it into the dildo slot.

Also I wonder if it wouldn't be easier to just plug each individual device into a USB slot directly? Trying to define a good standardized interface between the controller box and the devices kinda feels like reinventing what USB already is. If we gave every device a very simple chip to do the serial <-> parallel processing and then plug them into the USB port, then I think we would solve a lot of problems all at once.

nilcum wrote:The microcontroller I am thinking of using is the from Atmel's. The ATMega168 is basically an 8-Bit Processor. You get 16K of program space and 23 I/O lines. It will runs at about 20MHz. Best part is the cost $5.00 per unit. That may change if I think we need a beefier chip. The ARM stuff is generally more powerful, but also more expensive, and MUCH more difficult to deal with. There is an open source project called Arduino that uses this microcontroller that I think we would do well to base this stuff off of.

Sounds good. I also project that we might need a chip with a little more punch eventually.

nilcum wrote:Also, there is no reason to limit the daemon to only controlling hardware. It could very easily do other jobs like peer-to-peer networking and control, text-to-speech, microphone and webcam interactions (though flash also offers this), automatic-updates, anything else you can think of that would be a pain to do in flash or a browser?

Yes, it *could* do these things, but I'd rather be careful with adding too many features. Don't really see what you would need P2P for, since we have a server to take care of all communication needs, text-to-speech can be done through a webservice. And Microphone/webcam etc. are much, much better handled by Flash anyway. (Flash has very optimized video encoding/decoding and streaming capability as well as the corresponding server software, stuff that we can't even remotely dream of coming close to.)

I don't like the fact that we need a client. It's going to come at a high price. We have about 5000 daily visitors. Right now only about 0.2% of them ever have technical problems. That is because Flash is such a marvelous platform. It runs the same on all systems and it's very hard to screw it up. But the one thing it can't do is control custom hardware. And that's what we need the client for. There are just a lot of pitfalls on the way that we have to look out for.

nilcum wrote:Anyway, I know that was a long response. It was kind of a brain dump. For the short term, I want to iron out what the daemon should do, the language of choice, and implement a basic architecture and some of the simple feature.

Ok, I've responded to your comments, so I guess it's my time to brain dump.

First a list of components the base client should have and what they should be able to do:

Installer
Simple, quick, no hassle. Should install as a service, but there should be an entry in the Start menu, where you can start/stop/restart and uninstall it. Of course we can use a free installer package like NSIS for the installation and uninstallation and simple .LNKs to control the application.

Server
Super simple webserver, only accept local connections. And by simple I mean that simple. And that server even has authentication which we don't even need.

Module Interface
The best plugin system under Windows that I've ever seen is that of Foobar. You just download dll files and put them into the plugins directory. (We can always create a fancy plugin manager later, but for now this solution would save us the trouble of writing one while still being super-easy to use. I can elaborate more on the advantages of this plugin system if you would like me to.)

And that's it really. First module would be some kind of hello world, displayed by the client and triggered from a FlashTease, then we can move right on to the first hardware module.

The hottest candidate for a first hardware module would probably be this little fella. You can buy it online (sold out, but soon to return) and there is open source example C++ code where you can see exactly how to control it. And we can actually use their board design as a starting point for other toys in the future.

I think everything is pointing towards a minimalistic C++ program. We would come out somewhere in the <500 KB ballpark, which would be awesome. And it's pretty nondiscriminatory regarding what the modules contain since they are independent little DLLs, so if you want to do a module that uses .NET and text-to-speech and whatnot - you can. What I also find very charming about this plan is that we don't have to do any major development ourselves, we just have to take that webserver class, that vibrator class, wire it all up, turn it into a service and voila. - Trust me that's going to take long enough.

Other advantages of the C++ minimalistic solution include:
- Few dependencies means people are gonna have fewer problems.
- Simple plugin system means other developers are more likely to write their own modules. Every C++ developer knows what a dll is. If you give them the API and a few instructions they should be set to go. Plus we can look at the foobar2000 SDK for inspiration on how our SDK might look.

Regarding TENS: I just checked my TENS unit's manual. It's putting out 0 - 80 mA (at 0-70 V in a "modified rectangular pulse" with an impulse duration of 250 μs +/- 10% and frequency of 1-100 Hz.) The 500 mA that a USB port is putting out should be way more than enough. (I think 600 mA through the heart will kill you. I know - I watch too much CSI. ) The problem is more in the area of safety. I remember reading that TENS units are legally required to be battery-powered, because otherwise a surge in the power line could kill you. (Hmm, then again, I think the E212 is mains powered, right?) In any case, TENS is probably something we should take a loooooong time to plan carefully. One dead guy and we get a lot of time to think about the next revision in prison.

Regarding doing a controller box: Let's start with the simple USB vibe. Then we decide what to do next on the basis of all the stuff that we have learned by then. Maybe we'll decide to do a box, maybe something else, we'll see. Agreed?

There you go, brain dump complete.

PS: Requesting permission to post this discussion in the Team Forum as well. That ok with you?

nilcum wrote:Quick update. I've ordered an Arduino board. Should have it by next week. Costs $40 without power supply or USB cable. May not be what we end up going with over all but it will give a wonderful foundation.

Seeing that we 100% agree on both conditions, I'll put up a vote on admitting you to the Team. These votes run three days and I'll let you know about the outcome then.

Great, I know I'm a forum new comer but I've been a visitor for awhile. Thanks.

It's your decision. Cross-platform compatibility normally would be important to me, but since the interface is open, we can always write a Mac version of the client further down the road. Speed and "niceness" of the client would be more important. Users should not have any disadvantages from installing it and it should take as little resources as possible. I think C/C++ might fit the bill best. Not so sure about .NET. I associate it with buggy, amateurish and slow programs for which you first need to download a huge .NET runtime library which then screws up your already crappy Windows OS. But you know, I might be biased a *little*.

Seriously though, I leave it up to you. I've laid out our interest: We want a nice little program that does as little as necessary, runs fast, doesn't bug people, has few prerequisites, an easy installation and Just Works. Use whatever technology you would use to achieve these goals.

Cool.

I'm definitely not for Bluetooth and I agree about the advantages of USB.

One piece of advice I can give though is: Make a plan where the first payout is as early as possible. In our case that would probably mean using some USB vibrator that is already being produced in the Teledildonics scene and getting it to run with the client. Then we can get it to run with the FlashTease viewer, release it and check user reaction. If we manage to get that far, then we can think about the next step. It's just: If we start out too ambitious right away, there is a much higher risk we will never get anything done.

Agreed, I don't want to burnout on this and it will be nice to help out almost immediatly.

Also I wonder if it wouldn't be easier to just plug each individual device into a USB slot directly? Trying to define a good standardized interface between the controller box and the devices kinda feels like reinventing what USB already is. If we gave every device a very simple chip to do the serial <-> parallel processing and then plug them into the USB port, then I think we would solve a lot of problems all at once.

Trouble with this is simply cost. USB->serial devices will run about $20. All of the microcontrollers speak serial but very few do USB. There is one I was looking at: PIC18F4550 (similar to the one on the Rez vibe) might be a better solution. It costs $10 for 1.

Yes, it *could* do these things, but I'd rather be careful with adding too many features. Don't really see what you would need P2P for, since we have a server to take care of all communication needs, text-to-speech can be done through a webservice. And Microphone/webcam etc. are much, much better handled by Flash anyway. (Flash has very optimized video encoding/decoding and streaming capability as well as the corresponding server software, stuff that we can't even remotely dream of coming close to.)

One other thing I was thinking of was speech to text. That way a tease that instruct you to say something aloud could verify that it was actually said.

I don't like the fact that we need a client. But the one thing it can't do is control custom hardware. And that's what we need the client for.

Actually, flash can do serial communications. There are a few examples of this online. The problem is that if it is hard coded into the milovana flash tease it isn't something others could take advantage of in the same way a web browser could.

First a list of components the base client should have and what they should be able to do:

Installer
Simple, quick, no hassle. Should install as a service, but there should be an entry in the Start menu, where you can start/stop/restart and uninstall it. Of course we can use a free installer package like NSIS for the installation and uninstallation and simple .LNKs to control the application.

NSIS rules, I've used it before and love it.

Server
Super simple webserver, only accept local connections. And by simple I mean that simple. And that server even has authentication which we don't even need.

Yep. I'm sure with a little help from google I can find an existing HTTP server implementation.

Module Interface
The best plugin system under Windows that I've ever seen is that of Foobar. You just download dll files and put them into the plugins directory. (We can always create a fancy plugin manager later, but for now this solution would save us the trouble of writing one while still being super-easy to use. I can elaborate more on the advantages of this plugin system if you would like me to.)

I'll check out Foobar. Having a plugin system is a great idea. In addition to a core set of commands each HTTP command module could be implemented as a plugin.

The hottest candidate for a first hardware module would probably be this little fella. You can buy it online (sold out, but soon to return) and there is open source example C++ code where you can see exactly how to control it. And we can actually use their board design as a starting point for other toys in the future.

I think everything is pointing towards a minimalistic C++ program. We would come out somewhere in the <500 KB ballpark, which would be awesome. And it's pretty nondiscriminatory regarding what the modules contain since they are independent little DLLs, so if you want to do a module that uses .NET and text-to-speech and whatnot - you can. What I also find very charming about this plan is that we don't have to do any major development ourselves, we just have to take that webserver class, that vibrator class, wire it all up, turn it into a service and voila. - Trust me that's going to take long enough.

I'd expect less than 200k and I agree with pretty much all of the above.

Regarding TENS: I just checked my TENS unit's manual. It's putting out 0 - 80 mA (at 0-70 V in a "modified rectangular pulse" with an impulse duration of 250 μs +/- 10% and frequency of 1-100 Hz.) The 500 mA that a USB port is putting out should be way more than enough. (I think 600 mA through the heart will kill you. I know - I watch too much CSI. ) The problem is more in the area of safety. I remember reading that TENS units are legally required to be battery-powered, because otherwise a surge in the power line could kill you. (Hmm, then again, I think the E212 is mains powered, right?) In any case, TENS is probably something we should take a loooooong time to plan carefully. One dead guy and we get a lot of time to think about the next revision in prison.

Yeah, I'll need to research TENS a little bit more. Phaser seems to have done a lot of the ground work already. Also, the 500mA possible from the USB is only at 3v. It might be possible to get the voltage up to 70 with 80mA left. If nothing else it could be used to charge a capacitor that would be used to give a little shock. At any rate, you are right this is not the most immediate thing to implement.

Regarding doing a controller box: Let's start with the simple USB vibe. Then we decide what to do next on the basis of all the stuff that we have learned by then. Maybe we'll decide to do a box, maybe something else, we'll see. Agreed?

The USB vibe has enough IO on it to actually be the controller box! The vibe is only using one of the I think 16 pins. Might as well make room for the other interfaces as well. But I'm totally cool with the first attachment being a vibe. The motors are cheap and can easily be controlled with PWM.

PS: Requesting permission to post this discussion in the Team Forum as well. That ok with you?

Fine with me. Thanks.

nilcum wrote:Whoops, USB has 5v not 3v.

So:

5v/70v = x/500ma

x=35mA

I went scavenging for some step up transformers and couldn't find a single on in my house. Radio shack didn't have any either. I'll order a few different ones and actually measure the results.

seraph0x wrote:

nilcum wrote:Quick update. I've ordered an Arduino board. Should have it by next week. Costs $40 without power supply or USB cable. May not be what we end up going with over all but it will give a wonderful foundation.

Ok, have fun with it!

nilcum wrote:Trouble with this is simply cost. USB->serial devices will run about $20. All of the microcontrollers speak serial but very few do USB. There is one I was looking at: PIC18F4550 (similar to the one on the Rez vibe) might be a better solution. It costs $10 for 1.

Why not use the same one the Rez uses? It does everything we need (and then some) and it's only 5.92$ at Newark. (If you order >100 units, it's only 5.50$) Plus once we got the vibe running we can just copy and modify the firmware for each different type of device. Seems to me like the perfect choice for us.

It hasn't got native USB support, but that has already been figured out for us, we have the firmware for the Rez including an assembly USB stack. So we really don't need to worry about that. That probably saves us a lot more time than native USB support would.

nilcum wrote:One other thing I was thinking of was speech to text. That way a tease that instruct you to say something aloud could verify that it was actually said.

Sure, do a plugin for it if you like.

nilcum wrote:Actually, flash can do serial communications. There are a few examples of this online. The problem is that if it is hard coded into the milovana flash tease it isn't something others could take advantage of in the same way a web browser could.

Do you have an example? I'm pretty sure Flash can't do that. There are bridging projects like WiiFlash, but they are doing exactly what we are doing: You have to run a separate client.

nilcum wrote:Yeah, I'll need to research TENS a little bit more. Phaser seems to have done a lot of the ground work already. Also, the 500mA possible from the USB is only at 3v. It might be possible to get the voltage up to 70 with 80mA left. If nothing else it could be used to charge a capacitor that would be used to give a little shock. At any rate, you are right this is not the most immediate thing to implement.

Why should the max. current at the USB port change if you transform the voltage inside the device? In fact: I = V/R -- If you use a transformer to increase your voltage your current will first of all increase, unless you add more resistance to compensate. If you get the voltage up to 70V you need to add enough resistors to bring the current down to 500mA or 80 mA or whatever you want. As long as it stays below 500mA you're fine. Did I overlook something?

nilcum wrote:The USB vibe has enough IO on it to actually be the controller box! The vibe is only using one of the I think 16 pins. Might as well make room for the other interfaces as well. But I'm totally cool with the first attachment being a vibe. The motors are cheap and can easily be controlled with PWM.

Good observation. Good to know that the chip can also drive much more sophisticated devices.

I'm starting to be against using a controller box. You would have to:
- Define a interface between the box and the devices (with separate signal and power lines of course)
- Provide sockets, plugs and additional cables
- Detect what devices are plugged in
- Answer more support requests, because of the higher complexity
- Program a much more sophisticated firmware
- Convince people to buy the controller box, before you can sell them any devices
- Share USB power between devices or supply mains power at additional cost and complexity

And all that just so the vibe costs 23.99$ instead of 29.99$? Doesn't seem to be worth the trouble. Many people will only need one toy and then they'll be faced with some 30$ for the controller box and 23.99$ for the toy... not good.

nilcum wrote:

Why not use the same one the Rez uses? It does everything we need (and then some) and it's only 5.92$ at Newark. (If you order >100 units, it's only 5.50$) Plus once we got the vibe running we can just copy and modify the firmware for each different type of device. Seems to me like the perfect choice for us.

It hasn't got native USB support, but that has already been figured out for us, we have the firmware for the Rez including an assembly USB stack. So we really don't need to worry about that. That probably saves us a lot more time than native USB support would.

I actually looked at that. But, I didn't see a great development kit for that chip. I think people are turned off by the TINY 256 BYTE eeprom.

Do you have an example? I'm pretty sure Flash can't do that. There are bridging projects like WiiFlash, but they are doing exactly what we are doing: You have to run a separate client.

Somehow these people are doing it:

http://youtube.com/watch?v=49WBPIIo3EE
Do a youtube search for Arundio

(not flash but this is the reason why I ordered this kit) http://youtube.com/watch?v=g_hiz-Kx0kM

Why should the max. current at the USB port change if you transform the voltage inside the device? In fact: I = V/R -- If you use a transformer to increase your voltage your current will first of all increase, unless you add more resistance to compensate. If you get the voltage up to 70V you need to add enough resistors to bring the current down to 500mA or 80 mA or whatever you want. As long as it stays below 500mA you're fine. Did I overlook something?

So, you can't create power out of nothing. The power entering a transformer is equal to the power exiting the transformer (ideally). If the voltage is stepped up then the current is stepped down and vice-a-versa. It's more to do with induction law than ohms law. Wikipedia has a decent article on this: http://en.wikipedia.org/wiki/Transformer

So if we want to know the current after 3v -> 70v

3v/70v = x/500mA

x = (3*500)/70 = ~21mA.

0.0021 Amps at 70v is enough to pass through the human body so that is is perceptible and safe.

http://en.wikipedia.org/wiki/Electric_shock

I am defiantly not willing to send anything more than 100mA.

Again something to research further. I'm wondering what these numbers will look like after we calculate the current drawn to power the microcontroller.

I'm starting to be against using a controller box. You would have to:
- Define a interface between the box and the devices (with separate signal and power lines of course)
- Provide sockets, plugs and additional cables
- Detect what devices are plugged in
- Answer more support requests, because of the higher complexity
- Program a much more sophisticated firmware
- Convince people to buy the controller box, before you can sell them any devices
- Share USB power between devices or supply mains power at additional cost and complexity


And all that just so the vibe costs 23.99$ instead of 29.99$? Doesn't seem to be worth the trouble. Many people will only need one toy and then they'll be faced with some 30$ for the controller box and 23.99$ for the toy... not good.

So the controller box would be ~$40. Each toy after that could be at little as $5. Vibrating motors are very cheap. As are electromagnets, shocking circuits, etc. But if all of them needed a microcontroller and a USB interface it would be expensive. After two attachments, it is worth the extra initial cost. We are only talking about a difference of maybe $20 here. It may not be the best or cheapest solution but I've already ordered hardware so I am going to take my initial stab with that stuff. If it ends up being too expensive I'll look for a non-modular less expensive option.

Also, I have a windows service running http now. Written in C++. Basically the example you sent reworked to fit my programming style a little better and with some C service code wrapped around it. Simple and quick.

seraph0x wrote:

nilcum wrote:I actually looked at that. But, I didn't see a great development kit for that chip. I think people are turned off by the TINY 256 BYTE eeprom.

Hmm. Still low price per chip is a good argument. But I'll leave it up to you.

Arundio is a dev board, what would be the corresponding retail chip(s)?

Also, I have a windows service running http now. Written in C++. Basically the example you sent reworked to fit my programming style a little better and with some C service code wrapped around it. Simple and quick.

Very nice. Once the FlashTease editor preview is released to the public I'll try whether I can get Flash to send requests to localhost. (Since the swf is from http://www.milovana.com and the client is running as localhost we are talking about cross-domain communication. This means that the client will have to serve a policy file that tells Flash that the connection is allowed and legit. I've done that across domains before, but not with localhost. I hope Flash sees that as just another domain. I'll try it out and send you the policy file and the URL that your webserver should listen for.)

Somehow these people are doing it:

http://youtube.com/watch?v=49WBPIIo3EE
Do a youtube search for Arundio

(not flash but this is the reason why I ordered this kit) http://youtube.com/watch?v=g_hiz-Kx0kM

http://www.arduino.cc/playground/Interfacing/Flash

Comes with a small exe file you have to execute.

The exe uses sockets to communicate with Flash though instead of HTTP as we're planning it. Sockets would be better for asynchronous communication, but I'm not sure whether Flash allows cross-domain socket access. My guess would be that once you loaded the policy file, Flash unlocks all communication APIs for that domain, including sockets.

So, you can't create power out of nothing. The power entering a transformer is equal to the power exiting the transformer (ideally). If the voltage is stepped up then the current is stepped down and vice-a-versa. It's more to do with induction law than ohms law. Wikipedia has a decent article on this: http://en.wikipedia.org/wiki/Transformer

So if we want to know the current after 3v -> 70v

3v/70v = x/500mA

x = (3*500)/70 = ~21mA.

Hehe, ok. It's coming back now. I was thinking that since there is so-and-so many electrons coming in through the USB socket and the same amount exiting the current (electrons over time) should be constant. But I forgot that a transformer does not actually connect it's input and output, but instead works through electromagnetic coupling, so of course it's possible for the current to change. And since the voltage could be seen as a measure for how much work one electron is prepared to do there must be less electrons for the total energy to be preserved.

I did get an A in physics, but it's all so long ago.

Well, good thing I got you!

0.0021 Amps at 70v is enough to pass through the human body so that is is perceptible and safe.

21mA is 0.021A and according to your latest PM we're looking at a maximum of 0.035A. The 80 mA of the TENS are bearable depending on where you attach the unit. If you attach one electrode under the armpit and the other at the wrist, you'll get the "sustained involuntary contraction" Wikipedia puts at 10-20mA when it's turned up around half way. This is the power level I typically find myself using. So 35 mA should be a pretty good level. My concern with using USB power would be how to effectively protect agains power spikes.

I'm starting to be against using a controller box. You would have to:
- Define a interface between the box and the devices (with separate signal and power lines of course)
- Provide sockets, plugs and additional cables
- Detect what devices are plugged in
- Answer more support requests, because of the higher complexity
- Program a much more sophisticated firmware
- Convince people to buy the controller box, before you can sell them any devices
- Share USB power between devices or supply mains power at additional cost and complexity


And all that just so the vibe costs 23.99$ instead of 29.99$? Doesn't seem to be worth the trouble. Many people will only need one toy and then they'll be faced with some 30$ for the controller box and 23.99$ for the toy... not good.

So the controller box would be ~$40. Each toy after that could be at little as $5. Vibrating motors are very cheap. As are electromagnets, shocking circuits, etc. But if all of them needed a microcontroller and a USB interface it would be expensive. After two attachments, it is worth the extra initial cost. We are only talking about a difference of maybe $20 here. It may not be the best or cheapest solution but I've already ordered hardware so I am going to take my initial stab with that stuff. If it ends up being too expensive I'll look for a non-modular less expensive option.

Fair enough. But please remember that the cost isn't the only issue. Development effort is just as important, especially in a project that depends on volunteers.

In any case, we'll start with the Rez and see how that goes.


Cheers,

Seraph0x

nilcum wrote:

seraph0x wrote:
Hmm. Still low price per chip is a good argument. But I'll leave it up to you.

Arundio is a dev board, what would be the corresponding retail chip(s)?

This is the chip used on the Arduino board.

http://www.sparkfun.com/commerce/produc ... ts_id=7957

It's dirt cheap -- the cost comes in all the other components needed to safely interface it with a computer. The cost comes as death by 1000 cuts with these project.

http://www.arduino.cc/playground/Interfacing/Flash

Comes with a small exe file you have to execute.

LOL, that makes sense. Thanks for researching that.

The exe uses sockets to communicate with Flash though instead of HTTP as we're planning it. Sockets would be better for asynchronous communication, but I'm not sure whether Flash allows cross-domain socket access. My guess would be that once you loaded the policy file, Flash unlocks all communication APIs for that domain, including sockets.

Sockets or HTTP either way -- I've programmed enough of both. Not sure what flash has for security with this but it sound like you have that part under control. Right now the service only listens on 127.0.0.1 for connections so there is no outside port open. Also, do you have a default port in mind? I was going with 7786. Decimal for ASCII of MV. Doesn't really matter.

21mA is 0.021A and according to your latest PM we're looking at a maximum of 0.035A.

Yep, I'm American -- we don't do the whole metric thing very well .

So 35 mA should be a pretty good level. My concern with using USB power would be how to effectively protect agains power spikes.

The best way is to have it be battery operated. For a very simple implementation of this I could get one of the novelty shocking pens or whatever and make it turn on and off with the microcontroller. That might be the best and safest way to start something like this.

Fair enough. But please remember that the cost isn't the only issue. Development effort is just as important, especially in a project that depends on volunteers.

In any case, we'll start with the Rez and see how that goes.

Awesome.

I've also started looking at electromagnets. These should be no problem to power off the GPIO. I made one now that is easily holding the keys to a small padlock with 1.5v. Used the inside of CAT5 cable to wrap around a nail. I'm planning to, hammer just the tip of the nail into a small piece of wood, then attach a velcro dot to that piece of wood. Then you could hang that form the ceiling or whatever. The only think I don't like about the design is that you will need to run a pair wire up to the magnet. I was thinking headphone wire with the standard stereo jack on the end. It is light and flexible and it has a common physical interface. I could do it with one wire and a battery too *shrug*.

Still waiting on the Arduino board to get in -- I'll let you know when it does. I think I have a parallax BS2 laying around someplace that I could start to experiment with. I will likely work on the client a bit more too.

seraph0x wrote:

nilcum wrote:Sockets or HTTP either way -- I've programmed enough of both. Not sure what flash has for security with this but it sound like you have that part under control. Right now the service only listens on 127.0.0.1 for connections so there is no outside port open. Also, do you have a default port in mind? I was going with 7786. Decimal for ASCII of MV. Doesn't really matter.

Apparently the only software that is using 7786 so far is a e-commerce solution called minivend which means a collision is extremely unlikely. The standard will not define the port though. We'll work out the details together later, but one thing that should work is if someone uses two different hardware clients. Because he has say our vibrator module and some other project's TENS or whatever. So the "Milovana Hardware Client" - we really need a proper name - will have 7786 as it's standard port, but the port can be changed and/or another client with another port can be used with the FlashTease system simultaneously.

Yep, I'm American -- we don't do the whole metric thing very well .

The best way is to have it be battery operated. For a very simple implementation of this I could get one of the novelty shocking pens or whatever and make it turn on and off with the microcontroller. That might be the best and safest way to start something like this.

Yes, that sounds perfect. The TENS I'm using is running off 9V power.

The shocking pen idea strikes me as a great, safe first version, but eventually it would be a big selling point for the solution as a whole to have the flexibility of a E212 or similar at a much lower cost which is something that should be theoretically possible since the attached PC can do all the processing and signal generation that makes the E212 so expensive.

As in - we'll use parts from a cheap USB soundcard and amplify them using the 9V. Then we can theoretically create any signal on the software side. There's probably even a sinus generator library open-source somewhere. It would just enable us software guys to endlessly try and play around with different sounds and waveforms.

Awesome.

I've also started looking at electromagnets. These should be no problem to power off the GPIO. I made one now that is easily holding the keys to a small padlock with 1.5v. Used the inside of CAT5 cable to wrap around a nail. I'm planning to, hammer just the tip of the nail into a small piece of wood, then attach a velcro dot to that piece of wood. Then you could hang that form the ceiling or whatever. The only think I don't like about the design is that you will need to run a pair wire up to the magnet. I was thinking headphone wire with the standard stereo jack on the end. It is light and flexible and it has a common physical interface. I could do it with one wire and a battery too *shrug*.

Hehe sounds like a pragmatic setup, I like it.

Cheers,

Seraph0x

nilcum wrote:

seraph0x wrote: Apparently the only software that is using 7786 so far is a e-commerce solution called minivend which means a collision is extremely unlikely. The standard will not define the port though. We'll work out the details together later, but one thing that should work is if someone uses two different hardware clients. Because he has say our vibrator module and some other project's TENS or whatever. So the "Milovana Hardware Client" - we really need a proper name - will have 7786 as it's standard port, but the port can be changed and/or another client with another port can be used with the FlashTease system simultaneously.

Of the hardware devices we've though about using so far. Most of them have to do four thing. Turn on, turn off, change levels, report back a status. Really, the fourth is not something I'm worried about just yet. So, all of these are trying to set some state in a device I think we should have a set command.

set <device number>:
power - on/off, 0 or 1
-- or --
level - number, 0-100

We should work over serial lines as a base standard because most hardware understands it. Not to say that there can't be something else in the middle like a USB -> serial or bluetooth-> serial. So long as we have a comport and can communicate by writing and reading to it.

So over a serial connection a set command might look like:
s1p1
-- or --
s1l50

9600 baud here is typical -- need to minimize data transfer. Anything connected to GPIO won't be able to have an associated level.

Over the web service it might look like this:
http://localhost:7786/set?device=1&power=1
http://localhost:7786/set?device=1&level=50

I think we should only use GET requests for the time being because we aren't going to be sending much information and they are very simple to use.

So, from the client perspective, each device will a unique id number and a COM number. The device number will be passed through the COM port.

I'm not sure what the rez is doing to control level. I imagine it still uses a COM port. I don't have one to play with.

The shocking pen idea strikes me as a great, safe first version, but eventually it would be a big selling point for the solution as a whole to have the flexibility of a E212 or similar at a much lower cost which is something that should be theoretically possible since the attached PC can do all the processing and signal generation that makes the E212 so expensive.

As in - we'll use parts from a cheap USB soundcard and amplify them using the 9V. Then we can theoretically create any signal on the software side. There's probably even a sinus generator library open-source somewhere. It would just enable us software guys to endlessly try and play around with different sounds and waveforms.

Werd. Great idea. The E212 looks really nice but yeah, the are reinventing a lot of what a PC can do. Now days, the PC might even be smaller than the E212.

So, my Arduino board came today. The development environment is not really supported on Vista so I spend a couple of hours hacking at it until I got something to work. The driver for the board was actually automatically found on Windows Update. Just had to be patient for the search to happen. I now have a blinking light. Turns on for 10 seconds, on for 1/2 a second the loops again. I'm going to see if I can get it to trigger the light over serial communications today. Should be easy as there are a few examples that already do this.

Also, the electromagnet lacked sufficient current over the GPIO to hold anything. I think I will have better luck with the PWM pins. Still hoping to power things off USB.

seraph0x wrote:

nilcum wrote:Of the hardware devices we've though about using so far. Most of them have to do four thing. Turn on, turn off, change levels, report back a status. Really, the fourth is not something I'm worried about just yet. So, all of these are trying to set some state in a device I think we should have a set command.

set <device number>:
power - on/off, 0 or 1
-- or --
level - number, 0-100

We should work over serial lines as a base standard because most hardware understands it. Not to say that there can't be something else in the middle like a USB -> serial or bluetooth-> serial. So long as we have a comport and can communicate by writing and reading to it.

So over a serial connection a set command might look like:
s1p1
-- or --
s1l50

9600 baud here is typical -- need to minimize data transfer. Anything connected to GPIO won't be able to have an associated level.

Over the web service it might look like this:
http://localhost:7786/set?device=1&power=1
http://localhost:7786/set?device=1&level=50

Mmhh. Makes sense for now. Let me go over what kind of interface I want to end up with eventually:

// The magnet's microcontroller should have it's own timer, because
// it needs to switch off automatically even if the computer crashes.
// If a timeout is already set, the new value overrides the old one.
// This way the software can always set timeouts of just a few seconds
// and keep the magnet switched on, while allowing it to timeout quickly
// in case the computer crashes.
http://localhost:7786/magnet?timeout=40

// The reason to use different plugins for different types of devices is
// that it allows us to keep complexity on the C++ side.
// Please note that you don't need to explicitly turn on/off. If the level is set to 0, the
// vibe turns off and any other level sets it to that power level and switches it on.
http://localhost:7786/vibe?power=40
// All plugins (that can have multiple devices of their type plugged in at
// once) should allow an ID parameter where 0 means "first vibrator",
// 1 means "second vibrator", i.e. the numbering is not influenced by
// other types of devices
http://localhost:7786/vibe?id=3&power=100
// Polling the number of vibes
http://localhost:7786/vibe?getlist

// Realistically, there will be our vibrator module called vibe and
// someone else's that might be called "supervibe" or whatever.
// Just pointing that out.

// Ok, here's for the TENS. It's being switched on in "wavegen" mode,
// i.e. the plugin is doing the sinus generation. Waveform is going to
// be square with a frequency of 50 and a power level of 20.
http://localhost:7786/estim?mode=wavege ... amp;lvl=20
// "mode=wavegen" and "type=square" might be defaults and so could be omitted.
// A single estim device however, might have several channels:
http://localhost:7786/estim?channel=2&a ... amp;lvl=10

Consider this a braindump.

I think we should only use GET requests for the time being because we aren't going to be sending much information and they are very simple to use.

So, from the client perspective, each device will a unique id number and a COM number. The device number will be passed through the COM port.

I'm not sure what the rez is doing to control level. I imagine it still uses a COM port. I don't have one to play with.

It uses regular USB. The microcontroller on the hardware side has an assembler USB stack and the host uses libUSB.

The actual call to set the vibe speed looks like this:

Code: Select all

usb_control_msg(cam, 0x41, 0x00, rate, 0x0300 + (rate & 0x0F), NULL, 0, 1000);   // 0x030X where X is the low nibble of rate

(The device variable is called "cam" because they copy&pasted code from another simplistic example that was talking to a Webcam.)

And the prototype for that function according to the libUSB docs is:

Code: Select all

int usb_control_msg(usb_dev_handle *dev, int requesttype, int request, int value, int index, char *bytes, int size, int timeout);

Werd. Great idea. The E212 looks really nice but yeah, the are reinventing a lot of what a PC can do. Now days, the PC might even be smaller than the E212.

So, my Arduino board came today. The development environment is not really supported on Vista so I spend a couple of hours hacking at it until I got something to work. The driver for the board was actually automatically found on Windows Update. Just had to be patient for the search to happen. I now have a blinking light. Turns on for 10 seconds, on for 1/2 a second the loops again. I'm going to see if I can get it to trigger the light over serial communications today. Should be easy as there are a few examples that already do this.

Also, the electromagnet lacked sufficient current over the GPIO to hold anything. I think I will have better luck with the PWM pins. Still hoping to power things off USB.

Also you don't have to carry the full weight of the key necessarily. You could hold a hook in place with the magnet that drops and releases the key if power is turned off or something like that.

nilcum wrote:Good point about power not being necessary. I've implemented the basics of this now. I've flashed my program onto the AVR chip and I have a working implementation that will receive commands of s1l0 and s1l1 and change a digital output line accordingly. It will also provide a verification response over the serial line.

After I get the electromagnet working I'm going to go back to developing the client. Hopefully I will be able to resolve the issues over the next few days. I might ask for a bit of help from the Arduino community. They seem very supportive.

As for a name, I suggest Tantalus.... http://en.wikipedia.org/wiki/Tantalus

I'll be in touch.

seraph0x wrote:

nilcum wrote:Good point about power not being necessary. I've implemented the basics of this now. I've flashed my program onto the AVR chip and I have a working implementation that will receive commands of s1l0 and s1l1 and change a digital output line accordingly. It will also provide a verification response over the serial line.

After I get the electromagnet working I'm going to go back to developing the client. Hopefully I will be able to resolve the issues over the next few days. I might ask for a bit of help from the Arduino community. They seem very supportive.

As for a name, I suggest Tantalus.... http://en.wikipedia.org/wiki/Tantalus

I'll be in touch.

Alright, you go ahead and do your thing, I'll be well occupied with the FlashTease editor for the next few days. If you have any news or if you'd like my opinion on something, let me know!

Tantalus is a hot candidate for the name. Tantalum in used in many hardware components like capacitors and such, so the name would even fit that bill.