IOIO Wishlist - tell us what you want!

5,765 views
Skip to first unread message

Ytai

unread,
Aug 2, 2011, 8:08:35 AM8/2/11
to ioio-...@googlegroups.com
Dear users,
I'd really like to spend my development efforts on things that people are actually going to use. So I'm starting this thread to figure out what features people would like to see in the next versions. Your votes will help me prioritize. Thanks in advance for your ongoing support!

I'm providing my own list - everyone is encouraged to add more items and/or to vote on items proposed by others:
  • Capacitive sensing - for easy connection of capacitive sensors.
  • PPM output - for connecting to a transmitter and controlling existing R/C toys.
  • IOIO over Bluetooth - support connecting a Bluetooth dongle to the IOIO USB jack and controlling it wirelessly using the exact same API. Will require a bootloader upgrade.
  • IOIO over OpenAccessory - use OpenAccessory (like ADK) as the underlying connection. Will improve latency and throughput. Possibly will not be 100% robust like the current version as result of OpenAccessory flaws. Will require a bootloader upgrade.
  • Parallel synchronous I/O - support clocked input / output using multiple pins in parallel.
  • Periodic digital sampling - obtaining precisely timed digital signals (e.g. for implementing a logic analyzer).
  • Bit-banging API - an advanced mode in which users will be able to write short scripts to run on the IOIO-side, which implement arbitrary protocols.
  • Increase analog sampling rate - expose an API for controlling the analog sampling rate (currently @1KHz / channel).
  • QEI - for communicating with quadrature encoders. Perhaps with a simpler mode for using unidirectional encoders.

Erle Czar Mantos

unread,
Aug 4, 2011, 4:58:11 AM8/4/11
to ioio-users
+1 to IOIO over Bluetooth.

On Aug 2, 5:08 am, Ytai <yta...@gmail.com> wrote:
> Dear users,
> I'd really like to spend my development efforts on things that people are
> actually going to *use*. So I'm starting this thread to figure out what
> features people would like to see in the next versions. Your votes will help
> me prioritize. Thanks in advance for your ongoing support!
>
> I'm providing my own list - everyone is encouraged to add more items and/or
> to vote on items proposed by others:
>
>    - *Capacitive sensing* - for easy connection of capacitive sensors.
>    - *PPM output* - for connecting to a transmitter and controlling existing
>    R/C toys.
>    - *IOIO over Bluetooth* - support connecting a Bluetooth dongle to the
>    IOIO USB jack and controlling it wirelessly using the exact same API. Will
>    require a bootloader upgrade.
>    - *IOIO over OpenAccessory* - use OpenAccessory (like ADK) as the
>    underlying connection. Will improve latency and throughput. Possibly will
>    not be 100% robust like the current version as result of OpenAccessory
>    flaws. Will require a bootloader upgrade.
>    - *Parallel synchronous I/O* - support clocked input / output using
>    multiple pins in parallel.
>    - *Periodic digital sampling* - obtaining precisely timed digital signals
>    (e.g. for implementing a logic analyzer).
>    - *Bit-banging API* - an advanced mode in which users will be able to
>    write short scripts to run on the IOIO-side, which implement arbitrary
>    protocols.
>    - *Increase analog sampling rate* - expose an API for controlling the
>    analog sampling rate (currently @1KHz / channel).
>    - *QEI* - for communicating with quadrature encoders. Perhaps with a

Eric42

unread,
Aug 5, 2011, 4:30:47 AM8/5/11
to ioio-users
Hi,

My main concern right now is easier developing/debugging (without
having to plug/unplug the ioio all the time). I guess IOIO over
bluetooth is a good step in this direction, so +1 for this one.

+1 for Periodical logical sampling too (with perhaps an option to use
a digital input as a trigger for capture instead of time reference)
+1 for Parallel synchronous I/O too
(I am not sure of the exact difference between "Periodical logical
sampling" and "Parallel synchronous I/O" with clocked input, but I
feel like they can both allow fun stuffs to be made :o) ).

I understood we already had OpenAccessory support, but I may be
wrong...

Other things I think would be nice to have (I can live without them,
but feel free to vote for them if you need them):
- Step motors driving
- Matrix keyboard reading
- Matricial led output (not sure of the name, but basically I'd like
to be able to control 64 leds using 16 binary outputs without having
to manually handle them)
PS:I am not sure the last one is possible (can the PIC do multi
thread?)

Eric

On 2 août, 14:08, Ytai <yta...@gmail.com> wrote:
> Dear users,
> I'd really like to spend my development efforts on things that people are
> actually going to *use*. So I'm starting this thread to figure out what
> features people would like to see in the next versions. Your votes will help
> me prioritize. Thanks in advance for your ongoing support!
>
> I'm providing my own list - everyone is encouraged to add more items and/or
> to vote on items proposed by others:
>
>    - *Capacitive sensing* - for easy connection of capacitive sensors.
>    - *PPM output* - for connecting to a transmitter and controlling existing
>    R/C toys.
>    - *IOIO over Bluetooth* - support connecting a Bluetooth dongle to the
>    IOIO USB jack and controlling it wirelessly using the exact same API. Will
>    require a bootloader upgrade.
>    - *IOIO over OpenAccessory* - use OpenAccessory (like ADK) as the
>    underlying connection. Will improve latency and throughput. Possibly will
>    not be 100% robust like the current version as result of OpenAccessory
>    flaws. Will require a bootloader upgrade.
>    - *Parallel synchronous I/O* - support clocked input / output using
>    multiple pins in parallel.
>    - *Periodic digital sampling* - obtaining precisely timed digital signals
>    (e.g. for implementing a logic analyzer).
>    - *Bit-banging API* - an advanced mode in which users will be able to
>    write short scripts to run on the IOIO-side, which implement arbitrary
>    protocols.
>    - *Increase analog sampling rate* - expose an API for controlling the
>    analog sampling rate (currently @1KHz / channel).
>    - *QEI* - for communicating with quadrature encoders. Perhaps with a

Guillem

unread,
Aug 5, 2011, 10:03:02 AM8/5/11
to ioio-...@googlegroups.com
+1 to IOIO over Bluetooth
+1 to IOIO over ADK 

Thanks!

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.


Ytai

unread,
Aug 5, 2011, 10:40:58 AM8/5/11
to ioio-...@googlegroups.com
@Eric

(I am not sure of the exact difference between "Periodical logical 
sampling" and "Parallel synchronous I/O" with clocked input, but I
feel like they can both allow fun stuffs to be made :o) ).

Good point. Periodic sampling may be achieved by parallel input with an internal clock, where the clock simply isn't output on any pin. 


I understood we already had OpenAccessory support, but I may be
wrong...

We do. However, it is in Beta mode, meaning that compatibility and support are not guaranteed, and it is not as robust as the ADB version. The purpose of this item is to release it properly on the main development branch. 
 

Other things I think would be nice to have (I can live without them,
but feel free to vote for them if you need them):
- Step motors driving
- Matrix keyboard reading
- Matricial led output (not sure of the name, but basically I'd like
to be able to control 64 leds using 16 binary outputs without having
to manually handle them)
PS:I am not sure the last one is possible (can the PIC do multi
thread?)
 All are great ideas! Not sure why multithreading is needed here: IIUC, you mean connecting the 64-LED to 8 anode and 8 cathode busses in a row-column setup and then quickly scanning (effectively achieving 1/8 power to each LED). You'd also need transistors on each row-column, or else you'd need to really choke the current. Is that what you meant? But by all means, this is a cool feature to add, i.e. implement the scanning and switching on the IOIO-side, where the Android side just says "I want these LED on now".

Joal Heagney

unread,
Aug 6, 2011, 8:25:16 PM8/6/11
to ioio-...@googlegroups.com
I know this is asking for a lot, but scripting support?
Maybe through:

http://code.google.com/p/android-scripting/

Joal Heagney

Ytai Ben-Tsvi

unread,
Aug 7, 2011, 2:25:16 AM8/7/11
to ioio-...@googlegroups.com, damon...@gmail.com
Yo, Damon,
See Joal's request below on the ioio-users list. I seem to recall you had a plan to support IOIO on SL4A, but I might be delusional...

Ytai.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/dQ5BrUQKcUQJ.

Ytai Ben-Tsvi

unread,
Aug 7, 2011, 11:13:52 AM8/7/11
to Damon, ioio-...@googlegroups.com, android-...@googlegroups.com
Forwarding Damon's response to the group.

On Sun, Aug 7, 2011 at 2:11 PM, Damon <damon...@gmail.com> wrote:
+android-scripting

I'm happy to accept patches for SL4A support. I unfortunately don't
have time to spend implementing it myself.

Damon

Manuel Naranjo

unread,
Aug 8, 2011, 9:05:17 AM8/8/11
to android-...@googlegroups.com, Damon, Ytai Ben-Tsvi, ioio-...@googlegroups.com
I would love to work on this, but I don't have any 2.3 Android device,
or IOIO board to play with.


> +android-scripting
>
> I'm happy to accept patches for SL4A support. I unfortunately don't
> have time to spend implementing it myself.
>
> Damon
>
> On Sun, Aug 7, 2011 at 8:25 AM, Ytai Ben-Tsvi<yta...@gmail.com> wrote:

Ytai Ben-Tsvi

unread,
Aug 8, 2011, 3:32:39 PM8/8/11
to Manuel Naranjo, android-...@googlegroups.com, Damon, ioio-...@googlegroups.com
Any Android >1.5 is good. But you will probably need a IOIO (unless you want to build a wrapper around a library that you won't be able to use...)
I can't offer you a IOIO (since I'll be paying for it just like everyone else), but you can win eternal glory, for which $50 are really a small price to pay :D

Manuel Naranjo

unread,
Aug 9, 2011, 8:34:44 AM8/9/11
to Ytai Ben-Tsvi, android-...@googlegroups.com, Damon, ioio-...@googlegroups.com
Ytai,
Any Android >1.5 is good.
Ohh right this isn't the Android Open Accessory

But you will probably need a IOIO (unless you want to build a wrapper around a library that you won't be able to use...)
Not even crazy I do it without the board!


I can't offer you a IOIO (since I'll be paying for it just like everyone else), but you can win eternal glory, for which $50 are really a small price to pay :D
I'm in Argentina right now, 50$ here is a lot of money, but lucky I'm comming to the US next month for a 4 month internship, I will get the board, and if I manage start working on the API.

Manuel

Ytai Ben-Tsvi

unread,
Aug 9, 2011, 2:22:07 PM8/9/11
to Manuel Naranjo, ioio-...@googlegroups.com, Damon, android-...@googlegroups.com

Great news. We'll keep in touch then!

On Aug 9, 2011 3:34 PM, "Manuel Naranjo" <naranjo...@gmail.com> wrote:
> Ytai,
>> Any Android >1.5 is good.
> Ohh right this isn't the Android Open Accessory
>
>> But you /will/ probably need a IOIO (unless you want to build a

Eric42

unread,
Aug 10, 2011, 2:50:20 AM8/10/11
to ioio-users
Hi,

On 5 août, 16:40, Ytai <yta...@gmail.com> wrote:
> @Eric
> (I am not sure of the exact difference between "Periodical logical
>
> > sampling" and "Parallel synchronous I/O" with clocked input, but I
> > feel like they can both allow fun stuffs to be made :o) ).
>
> Good point. Periodic sampling may be achieved by parallel input with an
> internal clock, where the clock simply isn't output on any pin.

OK, by "clocked" you mean "with a clock pin", not with a timer
trigger :o).

> > Other things I think would be nice to have (I can live without them,
> > but feel free to vote for them if you need them):
> > - Step motors driving
> > - Matrix keyboard reading
> > - Matricial led output (not sure of the name, but basically I'd like
> > to be able to control 64 leds using 16 binary outputs without having
> > to manually handle them)
> > PS:I am not sure the last one is possible (can the PIC do multi
> > thread?)
>
>  All are great ideas! Not sure why multithreading is needed here: IIUC, you
> mean connecting the 64-LED to 8 anode and 8 cathode busses in a row-column
> setup and then quickly scanning (effectively achieving 1/8 power to each
> LED).

Yes. I thought multi thread because if we want the leds to look like
they're lit all the time, we need to turn them on/off all the time,
but I guess you may include this to the micro-controler's main loop
(if there is such a thing... sorry if I say stupid things here but I
am not very experienced in micro-controlers (yet)).

> You'd also need transistors on each row-column, or else you'd need to
> really choke the current. Is that what you meant? But by all means, this is
> a cool feature to add, i.e. implement the scanning and switching on the
> IOIO-side, where the Android side just says "I want these LED on now".

I don't see why transistors are needed here but I'll try to understand
it before I burn my IOIO :o)

About the matrix input keyboard, I was thinking to some instruction
that will hang until a key is pressed of a timeout occurs and return
the pressed key code, but if you can manage the leds output matrix in
continue, perhaps you can use some extra cycles to continually scan
the keyboard and allow reading them in a buffered way?

If wishes season is still open, it would be nice to add RC5 protocol
support (both for emission and reception).
Bit banging scripts should allow it but if we can go native.

Eric

Ytai Ben-Tsvi

unread,
Aug 10, 2011, 4:01:11 AM8/10/11
to ioio-...@googlegroups.com

OK, by "clocked" you mean "with a clock pin", not with a timer
trigger :o).

I mean that you'll have something like the following options:
  • Each pin can be designated as input or output.
  • Clock source can be either internal (i.e. using an internal timer) or external (i.e. coming from a designated pin, generated externally). In case it is internal, you can additionally request that it is output on a certain pin.
This would give you quite a variety of options, one of which is periodic sampling (i.e. set pin(s) as input, internal clock, do not output the clock).


> > Other things I think would be nice to have (I can live without them,
> > but feel free to vote for them if you need them):
> > - Step motors driving
> > - Matrix keyboard reading
> > - Matricial led output (not sure of the name, but basically I'd like
> > to be able to control 64 leds using 16 binary outputs without having
> > to manually handle them)
> > PS:I am not sure the last one is possible (can the PIC do multi
> > thread?)
>
>  All are great ideas! Not sure why multithreading is needed here: IIUC, you
> mean connecting the 64-LED to 8 anode and 8 cathode busses in a row-column
> setup and then quickly scanning (effectively achieving 1/8 power to each
> LED).

Yes. I thought multi thread because if we want the leds to look like
they're lit all the time, we need to turn them on/off all the time,
but I guess you may include this to the micro-controler's main loop
(if there is such a thing... sorry if I say stupid things here but I
am not very experienced in micro-controlers (yet)).

Typically this is achieved by using timer interrupts. The PIC has 5 programmable timers, that can raise interrupts at your desired frequency. Some of them are already purposed, but there are still 2-3 free ones. 
 

> You'd also need transistors on each row-column, or else you'd need to
> really choke the current. Is that what you meant? But by all means, this is
> a cool feature to add, i.e. implement the scanning and switching on the
> IOIO-side, where the Android side just says "I want these LED on now".

I don't see why transistors are needed here but I'll try to understand
it before I burn my IOIO :o)

Each pin potentially sources / sinks 8 LED. At 10mA / LED, you'll have 80mA which is way above what the pin can handle. So you'd probably need PNP for the anodes (8 total) and NPN for the cathodes (8 total), as well as a current limiting resistor per-LED).
 

About the matrix input keyboard, I was thinking to some instruction
that will hang until a key is pressed of a timeout occurs and return
the pressed key code, but if you can manage the leds output matrix in
continue, perhaps you can use some extra cycles to continually scan
the keyboard and allow reading them in a buffered way?
 
No need to scan probably. You can get a "change notify" interrupt when a pin changes state. This is being used currently for digital input. So it is possibly just a different interpretation of these interrupts when they occur.
 

If wishes season is still open, it would be nice to add RC5 protocol
support (both for emission and reception).
Bit banging scripts should allow it but if we can go native.
 
Is this the protocol commonly used by TV remotes? If so, it is probably indeed a good idea! My guess is that bit-banging can take some time, and will be a little tricky to use properly. It is probably useful for exotic and rare protocols that are not worthy for properly implementing in firmware. So any common protocol should probably be 'hard coded' (which would also be more efficient). Then again, perhaps it will eventually be proved that the bit-banging option is so convenient that there's no point in hard-coding anything... Time will tell. Anyway, added to the wish-list!
 

Eric


--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

trandi

unread,
Aug 10, 2011, 6:06:30 AM8/10/11
to ioio-users
Manuel,

What project do you have in mind with the IOIO ?
I hate when money is an issue stopping a great project (even though
the whole point of hacking IS to do with re-cycled and cheap stuff...
lol...)

If you have a good idea about an interesting project, then send me
your address and I'll post you a IOIO board.

dan



On Aug 9, 1:34 pm, Manuel Naranjo <naranjo.man...@gmail.com> wrote:
> Ytai,> Any Android >1.5 is good.
>
> Ohh right this isn't the Android Open Accessory
>
> > But you /will/ probably need a IOIO (unless you want to build a

Manuel Naranjo

unread,
Aug 10, 2011, 7:59:54 AM8/10/11
to ioio-...@googlegroups.com
Dan,

> What project do you have in mind with the IOIO ?
Other than having the sake of fun??? :D, someone suggested that an SL4A
(meaning Python, PHP, Perl, Ruby and even JS) IOIO interface layer would
be nice to have. And I totally agree, it would let non Java developers
(for example artists) to create great thinks with the board.

Right now I don't have any other project, I just love new challanges and
playing with gadgets, I'm one of the core Py4A developers, and I think
I'm the only EE there, so I think I could be the guy to do it.

> I hate when money is an issue stopping a great project (even though
> the whole point of hacking IS to do with re-cycled and cheap stuff...
> lol...)

Yes money is an issue of course, also is time. As I said next month I'm
starting an internship in the US 'til end December, so that means I will
not have much time. But on the other hand is cheaper and easier for me
to ask sparkfun for a board once I'm there.

> If you have a good idea about an interesting project, then send me
> your address and I'll post you a IOIO board.

I can give you my US address as soon as I have it

Stupid question, I haven't investigated the IOIO board much, it's not
like the Arduino where you change the firmware on the fly keeping the
bootloader right? Specially what I mean is, do you write Java code to
modify the firmware? Because if that's the case, I don't think it would
make non developers life easier, and the project might not make sense at
all (still like the challenge).

Manuel

Ytai Ben-Tsvi

unread,
Aug 10, 2011, 1:53:02 PM8/10/11
to ioio-...@googlegroups.com
Stupid question, I haven't investigated the IOIO board much, it's not like the Arduino where you change the firmware on the fly keeping the bootloader right? Specially what I mean is, do you write Java code to modify the firmware? Because if that's the case, I don't think it would make non developers life easier, and the project might not make sense at all (still like the challenge).

In normal operation, there's a fixed firmware on the IOIO, which provides access to all the board's functions over a serial connection (currently on top of ADB or OpenAccessory, in the future maybe over Bluetooth, etc). It uses a certain well-defined protocol for exposing this functionality. On the other side of this connection (Android) is a Java library ("IOIOLib") used by the app, which wraps this protocol with a convenient high-level API. More info in: http://codaset.com/ytai/ioio/wiki

Having all that said - the IOIO boards do have a bootloader installed. This bootloader, upon restart, tries to establish a connection to the Android device and pull an application firmware, if available. Obtaining and selecting which firmware will be installed on the IOIO is done using an app called IOIO Manager (http://codaset.com/ytai/ioio/wiki/The-IOIO-Manager-Application). Although with the IOIO Manager it is possible to use it for running any code on the IOIO, it is normally used only for upgrading the "stock" firmware.

I think the intention when talking about exposing IOIOLib in SL4A was to wrap IOIOLib (or re-implement it and expose equivalent functionality) and expose this functionality to scripting languages. Will be very happy to get you engaged in this project!

Ytai

Manuel Naranjo

unread,
Aug 10, 2011, 4:06:46 PM8/10/11
to ioio-...@googlegroups.com
El 10/08/11 14:53, Ytai Ben-Tsvi escribió:
Ok in that case it makes total sense! I was afraid that we needed any dex byte code on the fly conversion.

I will take a look when I get the time, if anyone wants to start working on creating a facade I would love to help.

Manuel

A.Bergvall

unread,
Aug 15, 2011, 2:35:45 AM8/15/11
to ioio-...@googlegroups.com
I'm new to ioio but I haven't seen any features like this. Correct me if I'm wrong.
 
I would like to read input from a motor encoder (or more likely the commutation spikes), but since I don't need an extreme resolution with many pulses per motor turn, it would be nice to either:
1. Have a "wait for N inputs" which would in essence downsample the incoming pulses, or
2. Have a counter which can be polled from the Android device
 

Joal Heagney

unread,
Aug 15, 2011, 5:58:54 AM8/15/11
to ioio-...@googlegroups.com, Damon, android-...@googlegroups.com
Hi Ytai,

From my understanding of android-scripting, even a Java app that exposed the IOLib function calls as a series of intents would be enough of a start to enable writing an ioio library in python.

http://code.google.com/p/android-scripting/wiki/ApiReference#startActivityForResult

Thanks,

Joal Heagney

tormentor

unread,
Aug 17, 2011, 6:56:53 AM8/17/11
to ioio-...@googlegroups.com
Add 1-wire interfacing to API

tormentor

unread,
Aug 17, 2011, 7:12:36 AM8/17/11
to ioio-...@googlegroups.com
Another wish - porting of the IOIO API to desktop Java

Ytai Ben-Tsvi

unread,
Aug 17, 2011, 4:41:00 PM8/17/11
to ioio-...@googlegroups.com
@Joal, I suspect intents are really heavy compared to function calls in terms of latency and CPU required, but my intuition may be wrong.
@tormentor, I think there are several things called one-wire. Can you point me to a specific spec or device? I some cases I know of, one-wire is simply a UART operating in open-drain mode, with TX/RX connected together.
@tormentor, once BlueTooth is available (soon I hope), it will be possible to use IOIO from a PC.

On Wed, Aug 17, 2011 at 2:12 PM, tormentor <eda...@gmail.com> wrote:
Another wish - porting of the IOIO API to desktop Java

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/nsc0S3d2124J.
Message has been deleted

tormentor

unread,
Aug 19, 2011, 6:37:03 AM8/19/11
to ioio-...@googlegroups.com
>>> I think there are several things called one-wire. Can you point me to a specific spec or device?

http://www.maxim-ic.com/products/1-wire/

Ytai Ben-Tsvi

unread,
Aug 21, 2011, 9:40:27 AM8/21/11
to ioio-...@googlegroups.com

Got it. Great!

BASH

unread,
Aug 22, 2011, 4:06:21 AM8/22/11
to ioio-users
Wow, am I really the only person that would like a solution to be able
to connect a usb peripheral to the IOIO board? Does anybody agree that
this could be very useful. Thanks

mark gross

unread,
Aug 22, 2011, 9:56:55 AM8/22/11
to ioio-...@googlegroups.com
Any usb endpoint that presents itself as an ADB gadget will work ;)

--mark

> --
> You received this message because you are subscribed to the Google Groups "ioio-users" group.

> To post to this group, send email to ioio-...@googlegroups.com.
> To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.
>
>

--
do interesting things.

Ytai Ben-Tsvi

unread,
Aug 25, 2011, 12:23:45 AM8/25/11
to ioio-...@googlegroups.com
@Bash,
I agree that this would be useful, i.e. connecting a hub to IOIO and then an Android device on the other end plus some USB devices, and allow the Android to communicate with them somehow.
However, it is not very clear what would be the right API on the phone side for that, nor what parts of the stack will be implemented on IOIO and what parts on the Android.
Did you have any concrete idea in mind? Did you imagine something generic that would require device-specific drivers on the Java end or something more intuitive on the Java side that would require device-specific code on the IOIO?

Sam West

unread,
Aug 28, 2011, 6:53:39 PM8/28/11
to ioio-...@googlegroups.com
+1 for Increase analog sampling rate

(as discussed here: https://groups.google.com/forum/#!msg/ioio-users/MN2RopVVx-s/bCTzLKb6x_MJ)

Essentially, it would be really useful for myself (and a bunch of developers I work with) to be able to sample multiple analogue channels at high frequency (ie >1kHz).
This would allow you to use your phone as an oscilloscope!

Michael Shiloh

unread,
Aug 28, 2011, 7:20:20 PM8/28/11
to ioio-...@googlegroups.com
+1. Also spectrum analyzer (at whatever freq it can handle).

(You know, with an outboard FPGA it could do software radio too...)

mcstellar

unread,
Sep 12, 2011, 4:55:30 PM9/12/11
to ioio-...@googlegroups.com
+1 Parallel synchronous I/O

olli pyynönen

unread,
Sep 13, 2011, 4:08:36 AM9/13/11
to ioio-...@googlegroups.com
Sorry Mc Stellar, but do you mean separate I/O´s working independently but also simultaniously?
From that; can you send commands via USB many at same time or only one at time (as chain)? ;)

2011/9/12 mcstellar <jwhi...@gmail.com>
+1 Parallel synchronous I/O

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/qKu8tB_3TycJ.

To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.



--
Olli Pyynönen
+358(0)451188838
+358(0)404467015
olli.p...@gmail.com

gaetano mercante

unread,
Sep 28, 2011, 9:17:43 AM9/28/11
to ioio-...@googlegroups.com
+1 to IOIO over OpenAccessory
+1 to IOIO over Bluetooth

olli pyynönen

unread,
Oct 2, 2011, 3:31:29 AM10/2/11
to ioio-...@googlegroups.com
Yes, two (or more) i/o-channel can be connected simultaniously! Prooved!

2011/9/13 olli pyynönen <olli.p...@gmail.com>



--
Olli Pyynönen
olli.p...@gmail.com

evillanueva

unread,
Oct 29, 2011, 8:51:22 AM10/29/11
to ioio-users
now that USB Bluetooth Support is working great, i would like to wish
IOIO support to USB Wifi Dongle and USB Modem. (preferably HUAWEI Usb
Modems)
Connecting USB Modem to IOIO will give IOIO connection to Android
device over Internet. that would be a break through. :-)

Simpler wish would be 1-wire interface for devices such as
DS18B20. :-)

thanks

Mathew Key

unread,
Nov 7, 2011, 9:24:21 AM11/7/11
to ioio-...@googlegroups.com
As far as OneWire is concerned, the folks doing the Bus Pirate (www.dangerousprototypes.com) have One Wire as part of their product which is all open source.

kiz

unread,
Dec 28, 2011, 11:42:43 AM12/28/11
to ioio-...@googlegroups.com
The IOIO Manager should present a summary of the application and bootloader on any IOIO board.  This could be done at the startup, or via a menu item.

Ronald Niederhagen

unread,
Dec 29, 2011, 2:18:12 AM12/29/11
to ioio-...@googlegroups.com
That's a very good point!
Include a function in IOIO Manager to report Hardware ID, Bootloader ID
and Firmware ID, and some other interesting info which might be
available on the IOIO.


Am 28.12.2011 17:42, schrieb kiz:
> The IOIO Manager should present a summary of the application and
> bootloader on any IOIO board. This could be done at the startup, or

> via a menu item. --


> You received this message because you are subscribed to the Google
> Groups "ioio-users" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/ioio-users/-/EaOZP8pAkXkJ.

Ytai Ben-Tsvi

unread,
Dec 29, 2011, 3:33:54 AM12/29/11
to ioio-...@googlegroups.com
Good point indeed. Opened an issue for tracking: https://github.com/ytai/ioio/issues/11

On Wed, Dec 28, 2011 at 11:18 PM, Ronald Niederhagen <ronald.ni...@googlemail.com> wrote:
That's a very good point!
Include a function in  IOIO Manager to report Hardware ID, Bootloader ID and Firmware ID, and some other interesting info which might be available on the IOIO.


Am 28.12.2011 17:42, schrieb kiz:
The IOIO Manager should present a summary of the application and bootloader on any IOIO board.  This could be done at the startup, or via a menu item. --
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/EaOZP8pAkXkJ.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+unsubscribe@googlegroups.com.

Pretourian

unread,
Jan 3, 2012, 5:33:20 PM1/3/12
to ioio-...@googlegroups.com
How about a shiftout command? This is largely used in the industry. The ability to serially shift out data to a shift register like 74HC595 for instance. Check this out  http://www.parallax.com/dl/docs/books/sw/exp/sw23b.pdf With this approach we could easily extend I/O ports.

I would be happy to hear back from you on this

Best,

Fabio

Ytai Ben-Tsvi

unread,
Jan 3, 2012, 6:07:55 PM1/3/12
to ioio-...@googlegroups.com

This functionality can be achieved by using SPI (with an additional pin for latch if you will, or a falling edge trigger on the SS pin). The feature labelled parallel synchronous io above is a natural extension that would also support this use case (at slower rates probably, SPI can work at up to 8MHz).

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/BZ38lTxtPSQJ.

To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.

Alex Waller

unread,
Jan 4, 2012, 11:34:36 AM1/4/12
to ioio-...@googlegroups.com
If it isn't already supported (my IOIO is actually in the mail on the way to my house) I'd like to see support for HD44780 parallel LCD interface or TTL for a serial interface LCD. The project I have in mind requires an onboard display.

Ytai Ben-Tsvi

unread,
Jan 4, 2012, 12:10:20 PM1/4/12
to ioio-...@googlegroups.com
I think this would be covered by the "parallel / synchronous I/O" requirement.

On Wed, Jan 4, 2012 at 8:34 AM, Alex Waller <rella...@gmail.com> wrote:
If it isn't already supported (my IOIO is actually in the mail on the way to my house) I'd like to see support for HD44780 parallel LCD interface or TTL for a serial interface LCD. The project I have in mind requires an onboard display.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/eeNytsm7014J.

AETCNC

unread,
Jan 6, 2012, 7:18:55 AM1/6/12
to ioio-...@googlegroups.com
I would seriously...SERIOUSLY...like to be able to live-update the PWM freq of a PWM pin, for example in a SeekBar "onProgressChanged()" method. Believe it or not, there is HUGE application for this and it would be very very useful. I would do the IOIOLib changes myself, but cannot directly reference the PIC registers or re-flash the adjusted firmware obviously...
Please respond if this will be possible. Many thanks!

RobotFreak

unread,
Jan 24, 2012, 6:52:28 AM1/24/12
to ioio-...@googlegroups.com
Hi folks,
I would like to see UART with half-duplex (RS485) support for the next IOIO firmware. A concrete application for me would be to control Dynamixel servos like the AX-12. This can't be done from the Java side.
Because there is only a single line for receive/transmit you will need to disable the transmitter, when it is not used. Only when you want to send something you enable the transmitter, send the data, disable transmitter (when the last character has been send over the wire). For RS485 transceivers you will need a separate output pin to switch the direction of the RS485 IC between receive/transmit. 
Greatings Peter

Ytai Ben-Tsvi

unread,
Jan 24, 2012, 11:10:16 AM1/24/12
to ioio-...@googlegroups.com

Won't you achieve this by wiring rx and tx together, running tx in open drain and use an external pull up to 5v?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/zRemEUn5_QoJ.

Graeme Hulme-Jones

unread,
Jan 24, 2012, 1:04:27 PM1/24/12
to ioio-...@googlegroups.com

I agree...that should do it...

Rodrigo Magalhães

unread,
Jan 24, 2012, 1:10:15 PM1/24/12
to ioio-...@googlegroups.com
Hi people,
 
i would like to see some more elaborated electrical aspects, in order to avoid or prevent damages due to connection errors. Maybe, this kind of circuitry would be unnecessary on production PCBs, considering that, on these environments, we don't change connections very often, or don't change connections at all. I understand that this circuitry is likely to increase the PCB size, though...
 
Best regards,
Rodrigo Magalhães.

RobotFreak

unread,
Jan 24, 2012, 4:06:04 PM1/24/12
to ioio-...@googlegroups.com
Thanks, I will try that.

Simon Jackson

unread,
Jan 24, 2012, 7:03:14 PM1/24/12
to ioio-...@googlegroups.com
And reduce frequencies of input and output as resistance and capacitance exist.

achim....@gmail.com

unread,
Jan 25, 2012, 4:32:18 AM1/25/12
to ioio-...@googlegroups.com
Could you include some audio hardware (e.g. a vs1003 od vs1053)?

Android has a serious issue with audio latency. Basically, dynamic generated audio data needs about 150-200ms from the point in time when the data is handed over to Android until a sound can be heard (see http://code.google.com/p/android/issues/detail?id=3434). Using IOIO with some DACs or even some chip like the ones mentioned above, it would finally be possible to create audio apps matching the ones on iOS. BTW: it would be great to include a midi interface etc.

Wrapping this up into an easy to use product with according libs, this could solve a real long-time issue of Android!

Simon Jackson

unread,
Jan 25, 2012, 1:09:40 PM1/25/12
to ioio-...@googlegroups.com
So have you taken into account the .write buffer length can be part of the total .getMinBufferSize length?

Ytai Ben-Tsvi

unread,
Jan 25, 2012, 1:12:10 PM1/25/12
to ioio-...@googlegroups.com
Simon, I don't understand both your two last emails on this thread. Can you please elaborate?

On Wed, Jan 25, 2012 at 10:09 AM, Simon Jackson <jacko...@gmail.com> wrote:
So have you taken into account the .write buffer length can be part of the total .getMinBufferSize length?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/ILJqxUHiHkcJ.

Simon Jackson

unread,
Jan 25, 2012, 1:22:01 PM1/25/12
to ioio-...@googlegroups.com
I'm making a synth at the moment, and I think I will go MIDI later. I am aware that most professional MIDI sequencing software does allow for presending MIDI on a specific track so as to sync up with replay. In this sense only MIC->PCMOUT has an impossible to fix delay. I don't think the IOIO as an audio device would help, as there is no timing resolution to send the output. Perhaps a work around would be to use a UART Tx at the maximum baud, and use 1-bit DAC bitstream techniques, but this involves a Stream buffer overhead, and some parity/start/stop distortion.

Simon Jackson

unread,
Jan 25, 2012, 1:24:12 PM1/25/12
to ioio-...@googlegroups.com
As protection resistors are added to pins, the current which can flow to charge the pin capacitance is lowered, and so the maximum pin transition rate is reduced.

Simon Jackson

unread,
Jan 25, 2012, 1:40:36 PM1/25/12
to ioio-...@googlegroups.com
The getminbuffersize gets the minimum needed buffer to hold replaying sound while the system can do other things, so that enough sound is available to continue background playback. On write, if the buffer is full the call to write blocks, (probly on a fast copy routine filling the minimum buffer, and keeping it filled). In this sense the speed at which the blocked packet of sound can fill the minbuffersize buffer (hardware buffer) is perhaps fast enough, that if the minbuffer and write buffer are sufficiently large together, then there would be less delay. Maybe at best it could halve the delay.

This does assume of course that the buffer copy on write blocks and copies at quite a low level. If the blocking level is low enough, then the minbuffer has to be big enough for an interrupt service routine, and the write buffer written to it has to be getminbuffersize long. The latency will still be long, and perhaps this is not solvable unless the priority of the write refill process is increased. Is Thread.setpriority usable on android?

Cheers Jacko

achim....@gmail.com

unread,
Jan 25, 2012, 2:01:05 PM1/25/12
to ioio-...@googlegroups.com
I'm not taking about sequencing software but about using an android device as an instrument. Think about connecting a master keyboard to an android tablet. The tablet synthesizes the sound data. If that data is then handed over to android, android needs about 120-200 ms until a sound can be heard. That's way too much for an "instrument". So, since I cannot replace the android system on a customers device out there in the field, I'm thinking about bypassing it via the standard usb connection -> ioio -> (pcm) sound chip / dac -> speaker, wrapped up as a ready-to-buy interface. So the timing has not really to be synced in that case. Instead it should be "as fast as possible" / with a latency as low as possible (<50ms from pressing a key on the keyboard to hearing a sound).

Graeme Hulme-Jones

unread,
Jan 25, 2012, 2:48:45 PM1/25/12
to ioio-...@googlegroups.com

This sounds more an issue of including some facility in the firmware so that the API can support ADDITION of external chips to the IOIO at sufficient bandwidths. No offense to anyone, but I dont think there should be hardware addition to the IOIO...it narrows the device flexibility for other subject-specific-applications. The simplicity and adaptability of the IOIO is what will distinguish it against Apple et al.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/e4G0YvtkZsUJ.

achim....@gmail.com

unread,
Jan 25, 2012, 3:11:46 PM1/25/12
to ioio-...@googlegroups.com
You may be right that there should be no hardware addition to the IOIO. I don't want to offend anyone too, but thinking about it, what's needed is a product, a kind of "Android USB soundcard" that works right out of the box, not some do it yourself hardware (though that's much fun too). That "soundcard" could be based on the IOIO design or something different. I probably should try to find somebody who could help me to build and sell such a product.

Sanji Hanai

unread,
Jan 25, 2012, 3:51:51 PM1/25/12
to ioio-...@googlegroups.com

We can extend a IOIOLib for adding a functionality the API not offered, some useful resource is remained on the IOIO. Building the source is troublesome though.

If the MCU dose not have the virtual memory, it may be difficult to modularize and pluggable like IOIO Manager does. So how about writing a documentation for extend the IOIOLib and reserve the protocol number for it.

You may be right that there should be no hardware addition to the IOIO. I don't want to offend anyone too, but thinking about it, what's needed is a product, a kind of "Android USB soundcard" that works right out of the box, not some do it yourself hardware (though that's much fun too). That "soundcard" could be based on the IOIO design or something different. I probably should try to find somebody who could help me to build and sell such a product.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/_tslBxl5GnEJ.

Graeme Hulme-Jones

unread,
Jan 25, 2012, 4:32:41 PM1/25/12
to ioio-...@googlegroups.com

I may be that somebody ;)

On Jan 25, 2012 10:11 PM, "achim....@googlemail.com" <achim....@gmail.com> wrote:
You may be right that there should be no hardware addition to the IOIO. I don't want to offend anyone too, but thinking about it, what's needed is a product, a kind of "Android USB soundcard" that works right out of the box, not some do it yourself hardware (though that's much fun too). That "soundcard" could be based on the IOIO design or something different. I probably should try to find somebody who could help me to build and sell such a product.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/_tslBxl5GnEJ.

Ytai Ben-Tsvi

unread,
Jan 25, 2012, 9:24:08 PM1/25/12
to ioio-...@googlegroups.com

great stuff! An external hi-fi, low-latency sound card for Android is definitely something I would buy.
Even more so, if it had a midi in/out and an audio in/out and software for a synth, a guitar effect rack, a multichannel recorder, a sequencer, etc.

Something along the lines of Amplitube for iPhone.

Simon Jackson

unread,
Jan 25, 2012, 9:42:44 PM1/25/12
to ioio-...@googlegroups.com
Yes, most of the delay is the touch screen event delivery.

achim....@gmail.com

unread,
Jan 26, 2012, 1:38:35 AM1/26/12
to ioio-...@googlegroups.com
No, it's not the touchscreen that's causing this delay and not the event delivery. I measured it. It's the android software stack for audio output. See e.g. http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/ 

achim....@gmail.com

unread,
Jan 26, 2012, 2:53:25 AM1/26/12
to ioio-...@googlegroups.com
I send you a mail.

Ytai Ben-Tsvi

unread,
Jan 26, 2012, 4:38:16 AM1/26/12
to ioio-...@googlegroups.com

Allow me to focus the discussion a bit. The goal of this thread was to figure our which features would make IOIO a better product. Making a specific product based on IOIO is out of scope and I'm really hoping that this is something other people will do by leveraging the existing IOIO software.
In the context of audio that's been discussed above, the missing bit in IOIO is not a DAC but rather the API that will enable you to stream data out in a precise rate with high throughput and low latency.

We're talking about 1.5Mbit/sec or so, which should be doable.
What kind of interface would you like to see on the DAC side? SPI? Parallel synchronous? Something else?

On Jan 25, 2012 12:51 PM, "Sanji Hanai" <sanji...@gmail.com> wrote:
I send you a mail.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/blUR-mCYHxkJ.

Simon Jackson

unread,
Jan 26, 2012, 4:45:22 AM1/26/12
to ioio-...@googlegroups.com
A rough outline of the code I'm working on. Completing Control to handle the IOIO, and completing RenderThread to fill out sample generation. I may even get it to print the lag.

Cheers Jacko
M24-general-structure.tar.bz2

achim....@gmail.com

unread,
Jan 26, 2012, 5:39:49 AM1/26/12
to ioio-...@googlegroups.com
I probably would use either an VS1003 or VS1053B. According to their Data sheet, they appear to use SPI to transmit the audio data. I'm not into SPI enough to say more. I will try to figure it out. Until then, the data sheet for these chips can be found via Google. Sparkfun has a breakout board for the VS1053.

dain

unread,
Jan 26, 2012, 5:52:01 AM1/26/12
to ioio-users
Great discussion, I was onto the same idea (of making a high end
soundcard) when the IOIO was released (see:
https://groups.google.com/group/ioio-users/browse_thread/thread/a59cb1b41e4d66de/d98972a03bced468?lnk=gst&q=dain#d98972a03bced468
), but coming from a user interface / software development background
I gave up on the job of designing the hardware and embedded code
needed for it all alone.

Would be more than happy to join forces if some visual development /
UI design expertise is still needed, I have a bunch of ideas how
should this sound card control panel app on the Android side look like
and what features could it offer.

Ytai Ben-Tsvi

unread,
Jan 26, 2012, 1:20:14 PM1/26/12
to ioio-...@googlegroups.com
The VS* chips seems like an overkill: they do all the audio processing on-board and require the chip to be programmed. Since it has an SPI interface, it seems like the IOIO can already be used to communicate with it, perhaps with some little modifications that can save the round-trip to the Android in certain cases.
I thought the idea was to implement all the signal processing on the Android and only use an external DAC / ADC, which will probably require more work on the IOIO software, but will reduce costs and PCB size, and will also be more generic in the sense that your signal processing is part of the Android app and not another piece of firmware that need to be installed.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

achim....@gmail.com

unread,
Jan 27, 2012, 2:54:26 AM1/27/12
to ioio-...@googlegroups.com
Well, a DAC would be sufficient. However, if I think towards an "Android Soundcard", more functionality (2 x line in, encoder, ...) could be an advantage..

Yesterday, I wired up an Seeduino Mega (I don't a IOIO at hand) and a VS1053b breakout board to learn how to connect the VS1053b. The result:

"MP3-Mode"
    S0 <-> MISO
    S1 <-> MOSI
    SCLK <-> SCK
    CS <-> DOut / Chip Select
    DCS/BSYNC <-> DOut
    DREQ <->DIn

"Midi-Mode"
    RX <--> DOut/TX / (SoftSerial) 31250bps / Midi-Data

Optional (to reset & switch mode)
    Reset <-> DOut
    GPIO 0 <-> DOut
    GPIO 1 <-> DOut

The Midi sounds of the VS1053 are bad, so "Midi-Mode" is not really useful. The MP3-Mode is what's desired and this GPIO0/1 can be hard-wired. So, basically what's needed is SPI + 2x or 3x (with reset) DOut + 1x DIn. So, sorry, it seems as what I want to do already can be done with a IOIO.

Simon Jackson

unread,
Jan 28, 2012, 11:56:07 PM1/28/12
to ioio-...@googlegroups.com
I've thought about this, and it seems if no polyphony is required, then maybe an audiotrack with the sequence flush(), write(data), write(filler) would play data, almost instantly, as the filler would fill the buffer and block as it could be getminbuffersize() big. The following note would flush this if it was still waiting. The setup time of the audiotrack would be the only latency. MODE_STREAM.

The problem with continuous generation, is that flush() has some latency, and so there may be an issue with it. Hope this helps.

Cheers Jacko.

Ytai Ben-Tsvi

unread,
Jan 29, 2012, 3:06:24 AM1/29/12
to ioio-...@googlegroups.com
Bocar, Jacko, please take these discussions to another thread :)

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/Z9ILNqqYW8wJ.

a6000000

unread,
Feb 16, 2012, 8:10:32 AM2/16/12
to ioio-...@googlegroups.com
how to change the BlueTooth 4545   PASSCODE  to my own/different  passcode ?

Ytai Ben-Tsvi

unread,
Feb 16, 2012, 12:06:38 PM2/16/12
to ioio-...@googlegroups.com

This is hard coded in the firmware. You can change it and rebuild the firmware.

On Feb 16, 2012 5:10 AM, "a6000000" <com.6...@googlemail.com> wrote:
how to change the BlueTooth 4545   PASSCODE  to my own/different  passcode ?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/ZIdyxVVxreEJ.

Rob D

unread,
Feb 22, 2012, 1:30:04 PM2/22/12
to ioio-...@googlegroups.com
It would be valuable to be able to write to an external sd card hardware attachment via the pins on the IOIO board (easily, with an API supported by IOIOLib).  The reason is that many android devices don't have removable SD Cards, so any data created by an application attached to the Android device, that creates any sort of logs, makes the logs relatively hard to access.  (i.e. the user must move the Android device to within bluethooth range of a PC or other device, or connect the Android device to a PC to transfer any log files to the "internet.")  Of course some Android devices are also Phones, and email is an option in this case.  But, in many cases, simply pulling out an SD Card with the log data, and giving it to another person would simplify this procedure immensely.

Rob

smurry

unread,
Feb 23, 2012, 10:07:35 AM2/23/12
to ioio-users
+1 for this idea. I could use this function a lot.


--Stefan

Graeme Hulme-Jones

unread,
Feb 23, 2012, 10:35:06 AM2/23/12
to ioio-...@googlegroups.com

Just use easylogger from sparkfun...

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

smurry

unread,
Feb 24, 2012, 10:51:52 AM2/24/12
to ioio-users
Graeme,

Thanks, but I'm not trying to log data. My application involves
sending a datafile from my Android device through IOIO to an SD Card.
If you have an idea how the easylogger can do this, I'd love to know
it (seriously, not sarcastically!).

--Stefan

On Feb 23, 9:35 am, Graeme Hulme-Jones <ghj...@gmail.com> wrote:
> Just use easylogger from sparkfun...

Graeme Hulme-Jones

unread,
Feb 24, 2012, 11:09:35 AM2/24/12
to ioio-...@googlegroups.com
Sorry,

My fault completely...I meant 'openlog' from sparkfun. It logs a serial stream direct to a micro-SD card. The data stream can be whatever. By default it logs as a text file...but if you just match the file header of what ur trying to save then it will come up as that filetype on ur pc. This way all you do is pass your file out over serial...which IOIO already has API support for.

You get me? Or am I missing a finer detail of what ur doing?

Sent from Samsung Mobile



smurry <stefan...@gmail.com> wrote:


Al Linke

unread,
Mar 12, 2012, 3:28:13 PM3/12/12
to ioio-...@googlegroups.com
On the iPhone 4S and iPad 3, Apple has quietly done away with the previous M-Fi program allowing developers to access the new Bluetooth Low Energy chips in those devices without jailbreaking. Would be awesome to extend this to IOIO.

According to this paper on Bluetooth Low Energy, it's not meant for application with high data rate requirements and rather apps that need to occasionally send data.

I have seen a few folks using this, here's one example

Some Bluetooth Low Energy USB dongles are now available

http://www.bluegiga.com/BLED112_Bluetooth_low_energy_dongle

http://www.amazon.com/Medialink-USB-Bluetooth-Adapter-Technology/dp/B004LNXO28/ref=pd_cp_e_0






On Tuesday, August 2, 2011 5:08:35 AM UTC-7, Ytai wrote:
Dear users,
I'd really like to spend my development efforts on things that people are actually going to use. So I'm starting this thread to figure out what features people would like to see in the next versions. Your votes will help me prioritize. Thanks in advance for your ongoing support!

I'm providing my own list - everyone is encouraged to add more items and/or to vote on items proposed by others:
  • Capacitive sensing - for easy connection of capacitive sensors.
  • PPM output - for connecting to a transmitter and controlling existing R/C toys.
  • IOIO over Bluetooth - support connecting a Bluetooth dongle to the IOIO USB jack and controlling it wirelessly using the exact same API. Will require a bootloader upgrade.
  • IOIO over OpenAccessory - use OpenAccessory (like ADK) as the underlying connection. Will improve latency and throughput. Possibly will not be 100% robust like the current version as result of OpenAccessory flaws. Will require a bootloader upgrade.
  • Parallel synchronous I/O - support clocked input / output using multiple pins in parallel.
  • Periodic digital sampling - obtaining precisely timed digital signals (e.g. for implementing a logic analyzer).
  • Bit-banging API - an advanced mode in which users will be able to write short scripts to run on the IOIO-side, which implement arbitrary protocols.
  • Increase analog sampling rate - expose an API for controlling the analog sampling rate (currently @1KHz / channel).
  • QEI - for communicating with quadrature encoders. Perhaps with a simpler mode for using unidirectional encoders.

Elhanan Maayan

unread,
Mar 14, 2012, 5:21:40 AM3/14/12
to ioio-...@googlegroups.com
* a led indicating about a successful connection to android, (would be great if we'll have 2 for rxtx stuff)).
* a female barrel jack for easier power connection (so that morons like myself won't fry it by accident ;-) ).

docere

unread,
Mar 20, 2012, 1:15:51 AM3/20/12
to ioio-...@googlegroups.com
Here is an article that talks about using a UART to participate in 1-wire interface.  I have not tried this but this seems like a feasible solution

http://www.maxim-ic.com/app-notes/index.mvp/id/214 

On Friday, August 19, 2011 6:37:03 AM UTC-4, tormentor wrote:
>>> I think there are several things called one-wire. Can you point me to a specific spec or device?

http://www.maxim-ic.com/products/1-wire/

docere

unread,
Mar 20, 2012, 1:17:47 AM3/20/12
to ioio-...@googlegroups.com
http://www.maxim-ic.com/app-notes/index.mvp/id/214 

This is a useful article that talks about leveraging your UART to participate in 1-wire interfacing
Arnold

Ytai Ben-Tsvi

unread,
Mar 20, 2012, 2:23:42 AM3/20/12
to ioio-...@googlegroups.com
Interesting! Have you tried it? Seems to me that using the UART TX in open-drain and the UART RX in pull-up mode you may be able to use this with 0 external parts. The internal pull-up, however, may be too weak, so an external one might be required. Which is still not half bad if it works.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/8ogcHRcaMIMJ.

John Hewitt

unread,
Apr 1, 2012, 10:58:32 PM4/1/12
to ioio-...@googlegroups.com
Just wondering if anyone has tried the hardware stick-on joystick from joystick it:

http://www.youtube.com/watch?v=dscCGVzr65c

and if so what code is needed so i can use it with my ioio projects.

Ytai Ben-Tsvi

unread,
Apr 2, 2012, 12:22:51 PM4/2/12
to ioio-...@googlegroups.com
John, this device seems like it is meant to be placed on a touch screen and has nothing electronic about it - it only makes the touch screen believe your finer is at a certain position. So I can't seem much sense in connecting it with a IOIO.
Also, please consider the place where you're asking questions. It is better to open a new thread than ask a question on an unrelated thread.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/oMBmfYRuBYoJ.

Carl

unread,
Apr 3, 2012, 3:58:11 PM4/3/12
to ioio-...@googlegroups.com
I may just not know how to do it, but it would be nice to be able to set (and reset when needed) values for the pins which the device could reset to in the event of a lost connection.  This is probably more of an issue with the bluetooth dongles than the direct USB connection, but losing a connection can make an ioiobot run away from you.

Ytai Ben-Tsvi

unread,
Apr 3, 2012, 8:26:34 PM4/3/12
to ioio-...@googlegroups.com
When the connection is lost all the pins become floating. You should be able to use weak pull-ups pull-downs for getting a deterministic output when this happens. Does this satisfy your requirements?

On Tue, Apr 3, 2012 at 12:58 PM, Carl <carl.br...@gmail.com> wrote:
I may just not know how to do it, but it would be nice to be able to set (and reset when needed) values for the pins which the device could reset to in the event of a lost connection.  This is probably more of an issue with the bluetooth dongles than the direct USB connection, but losing a connection can make an ioiobot run away from you.

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/kVT6zhbUi5UJ.

Aaron Gascoigne

unread,
Apr 6, 2012, 3:54:40 PM4/6/12
to ioio-...@googlegroups.com
standalone mode so the ioio can do basic math without being connected to an android device(similar to bitbang?), I understand this is alot harder than it sounds

FelixA

unread,
May 20, 2012, 3:38:04 AM5/20/12
to ioio-...@googlegroups.com
IOIO over Wifi - support connecting a Wifi dongle to the IOIO USB jack and controlling it wirelessly using the exact same API would be really great. A simple webserver would be necessary to send commands from the Android phone <-> router <-> IOIO


Am Samstag, 29. Oktober 2011 14:51:22 UTC+2 schrieb evillanueva:
now that USB Bluetooth Support is working great, i would like to wish
IOIO support to USB Wifi Dongle and USB Modem. (preferably HUAWEI Usb
Modems)
Connecting USB Modem to IOIO will give IOIO connection to Android
device over Internet. that would be a break through. :-)

Simpler wish would be 1-wire interface for devices such as
DS18B20. :-)

thanks

tomer

unread,
Jun 4, 2012, 3:43:31 AM6/4/12
to ioio-...@googlegroups.com
.NET/C# library for Windows PC...


בתאריך יום שלישי, 2 באוגוסט 2011 15:08:35 UTC+3, מאת Ytai:

Ytai Ben-Tsvi

unread,
Jun 9, 2012, 12:14:07 PM6/9/12
to ioio-...@googlegroups.com

You know that Bluetooth and Accessory have been supported for quite a while, don't you?
PIC24H doesn't have USB OTG if I remember correctly.

On Jun 9, 2012 9:06 AM, "mfer17" <moi...@gmail.com> wrote:
+1 to IOIO over Bluetooth.
+1 to IOIO over OpenAccessory

New versions may incorporate a pic 24H.???
High performance 12-bit ADC ...

I am very interested in your work, congratulations ...

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/Kh97xQVEWLoJ.

Joey Carlini

unread,
Jun 18, 2012, 4:18:52 PM6/18/12
to ioio-...@googlegroups.com
Late to the party, but could IOIO place nice with Tasker, if all the programming is on the android anyway?

Vic Wintriss

unread,
Jun 28, 2012, 10:33:00 AM6/28/12
to ioio-...@googlegroups.com
Make pins configurable as input or output


On Tuesday, August 2, 2011 5:08:35 AM UTC-7, Ytai wrote:

Ytai Ben-Tsvi

unread,
Jun 28, 2012, 10:47:46 AM6/28/12
to ioio-...@googlegroups.com

Are you serious?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/2upuGW3smJoJ.

Dan Hockey

unread,
Jun 28, 2012, 11:03:16 AM6/28/12
to ioio-...@googlegroups.com
http://www.parallax.com/tabid/407/Default.aspx


On Thursday, June 28, 2012 9:33:00 AM UTC-5, Vic Wintriss wrote:
Make pins configurable as input or output

You could but you would have to use a different chip that supports that feature such as the following...
http://www.parallax.com/tabid/407/Default.aspx

The one down side of this is all the firmware would have to be rewritten.

Ytai Ben-Tsvi

unread,
Jun 28, 2012, 11:18:41 AM6/28/12
to ioio-...@googlegroups.com

I'm sorry. I don't understand what is the feature you are talking about exactly...

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/-xU8jMCJrxYJ.

Dan Hockey

unread,
Jun 28, 2012, 7:38:38 PM6/28/12
to ioio-...@googlegroups.com


On Thursday, June 28, 2012 10:18:41 AM UTC-5, Ytai wrote:

I'm sorry. I don't understand what is the feature you are talking about exactly...

Ok I'll try to explain...

Using parallax mcu's as an example, the basic stamp1, basic stamp2, and P8X32A have the ability to use an individual i/o pin or a group of i/o pins as an output or input configured via software. When configured as an output, the pin(s) has the ability to sink or source to control a PNP or NPN transistor and it also can send serial data out of any individual pin or a group of pins(for parallel data).

When configured for use as an input, a pin or a group of pins(for parallel data) can be used to read a high signal or a low signal. And any individual pin can be used for serial data input.
The P8X32A is able to do A to D as well.

    
It is loading more messages.
0 new messages