Accessory port

[mmatej]

As the accessory port is being ignored as an output port here (I haven't found here it's used somewhere), I created script that sends text string to the port.

Spoiler:

acsend.sh:

#!/bin/sh
ac='/sys/devices/system/mx50_accessory/mx50_accessory0/mx50_accessory_state'
rate=10000
nullstop=$(expr 3 \* ${rate})

get_chcode()
{
echo $(printf '%d' "$'$1")
}
binconv()
{
padto=0
[ ${#2} -ne 0 ] && padto=${2}
bstr=''
d=0
num=${1}
while [ ${num} -ne 0 ]; do
d=$(expr ${d} + 1)
bit=$(expr ${num} % 2)
bstr="${bit}""${bstr}"
num=$(expr ${num} / 2)
done
while true; do
[ ${padto} -eq 0 ] && break
[ ${d} -ge ${padto} ] && break
padleft=$(expr ${padto} - ${d})
bnulls=''
for i in $(seq 1 ${padleft}); do
bnulls="${bnulls}"'0'
done
bstr="${bnulls}""${bstr}"
break
done
echo "${bstr}"
}

[ ${#1} -eq 0 ] && return 1
str=''
for i in $(seq 0 $(expr ${#1} - 1)); do
code=$(get_chcode "${1:${i}:1}")
[ ${i} -ne 0 ] && str="${str}"' '
str="${str}""$(binconv ${code} 8)"
done
str="${str}"' '
sto=$(expr ${#str} - 1)
chp=0
echo -n "${1:${chp}:1}"
for i in $(seq 0 ${sto}); do
state="${str:${i}:1}"
[ "${state}" == ' ' ] &&
{
echo 0 > ${ac}
usleep ${nullstop}
chp=$(expr ${chp} + 1)
[ ${i} -ne ${sto} ] && echo -n "${1:${chp}:1}"
continue
}
echo ${state} > ${ac}
usleep ${rate}
done
echo

Connect the LED to the port and try it with ./acsend.sh 'Hello World!'!
Timing is very unreliable because it's shell script, but it's not bad anyway.

[geekmaster]

Originally Posted by mmatej

As the accessory port is being ignored as an output port here (I haven't found here it's used somewhere), I created script that sends text string to the port.

Spoiler:

acsend.sh:

#!/bin/sh
ac='/sys/devices/system/mx50_accessory/mx50_accessory0/mx50_accessory_state'
rate=10000
nullstop=$(expr 3 \* ${rate})

get_chcode()
{
echo $(printf '%d' "$'$1")
}
binconv()
{
padto=0
[ ${#2} -ne 0 ] && padto=${2}
bstr=''
d=0
num=${1}
while [ ${num} -ne 0 ]; do
d=$(expr ${d} + 1)
bit=$(expr ${num} % 2)
bstr="${bit}""${bstr}"
num=$(expr ${num} / 2)
done
while true; do
[ ${padto} -eq 0 ] && break
[ ${d} -ge ${padto} ] && break
padleft=$(expr ${padto} - ${d})
bnulls=''
for i in $(seq 1 ${padleft}); do
bnulls="${bnulls}"'0'
done
bstr="${bnulls}""${bstr}"
break
done
echo "${bstr}"
}

[ ${#1} -eq 0 ] && return 1
str=''
for i in $(seq 0 $(expr ${#1} - 1)); do
code=$(get_chcode "${1:${i}:1}")
[ ${i} -ne 0 ] && str="${str}"' '
str="${str}""$(binconv ${code} 8)"
done
str="${str}"' '
sto=$(expr ${#str} - 1)
chp=0
echo -n "${1:${chp}:1}"
for i in $(seq 0 ${sto}); do
state="${str:${i}:1}"
[ "${state}" == ' ' ] &&
{
echo 0 > ${ac}
usleep ${nullstop}
chp=$(expr ${chp} + 1)
[ ${i} -ne ${sto} ] && echo -n "${1:${chp}:1}"
continue
}
echo ${state} > ${ac}
usleep ${rate}
done
echo

Connect the LED to the port and try it with ./acsend.sh 'Hello World!'!
Timing is very unreliable because it's shell script, but it's not bad anyway.

Thanks! That has been on my "To Do" list for a long time (with no plans to do it any time soon). I am curious if the kindle can be charged through that port too -- if so you could also use it as an input port.

I was thinking of using the green and yellow power LEDs on a K4 to give it PWM stereo sound output (using photocells with color filters connected to an audio amplifier). Perhaps it would be easier to drive a speaker directly (with a current limiting resistor) if we PWM the accessory port output.

More karma for you!

EDIT: Not that it *really* matters when running programs from mmc (especially with this busybox that "short circuits" its own built-ins and ignores the "normal" load process), but the '[' conditional is a PROGRAM that loads and runs from the /bin folder (as I recall), but '[[' is an intrinsic that is executed directly by the shell. This really only makes a difference on non-busybox systems, but it is a good habit (even though it uses more characters on the line).

I love it when people take things off my "To Do" list:

2012-Mar-09:

Originally Posted by geekmaster

... Don't ask me "when" -- that project is WAY down on my "To Do" list. You can probably PWM the accessory power port (square metal pads on the bottom) to drive a speaker directly (with a current-limit resistor), if mono sound is okay. The pad just below the USB port is GND, and the other pad is +4V when enabled.

2012-Jun-11:

Originally Posted by geekmaster

... On the K4 and K5, the square pads on the back are ferrous so that you can connect to them with magnetic power connectors. To connect to these power pads, you could use tiny magnets taken from "magnetic stick and ball toys" (e.g. Magnetix brand), with wires attached, but then you would violate a patent for the obvious use of using magnets to attach a power connector (owned by Apple). On the K4 and K5, the ground pad is just above the USB jack, and power to the other jack is controlled by software (you can turn in on and off in diags). ...

[mmatej]

Originally Posted by geekmaster

Thanks! That has been on my "To Do" list for a long time (with no plans to do it any time soon). I am curious if the kindle can be charged through that port too -- if so you could also use it as an input port.

I was thinking of using the green and yellow power LEDs on a K4 to give it PWM stereo sound output (using photocells with color filters connected to an audio amplifier). Perhaps it would be easier to drive a speaker directly (with a current limiting resistor) if we PWM the accessory port output.

More karma for you!

Thanks for the karma! I think it could not be used as input port (also, I am not going to try it - there is currently no easy HW "unbrick"). While I was playing with the port, I've also tried to connect it to the piezo speaker and no way it could power speaker directly (even a piezo). I almost couldn't hear it (and with increasing freq -> decreasing volume).

Originally Posted by geekmaster

EDIT: Not that it *really* matters when running programs from mmc (especially with this busybox that "short circuits" its own built-ins and ignores the "normal" load process), but the '[' conditional is a PROGRAM that loads and runs from the /bin folder (as I recall), but '[[' is an intrinsic that is executed directly by the shell. This really only makes a difference on non-busybox systems, but it is a good habit (even though it uses more characters on the line).

Maybe next time.

[geekmaster]

Originally Posted by mmatej

Thanks for the karma! I think it could not be used as input port (also, I am not going to try it - there is currently no easy HW "unbrick"). While I was playing with the port, I've also tried to connect it to the piezo speaker and no way it could power speaker directly (even a piezo). I almost couldn't hear it (and with increasing freq -> decreasing volume).

Maybe next time.

Piezo earphones can be heard quite loudly driven by a germanium diode (1N34A or quivalent, as used in old "crystal set radios"). Perhaps your piezo speaker element wants 5 volts?

I would think that anything that can power an LED could surely drive earphones.

Also, piezo "speakers" are very frequency sensitive, with a small range of resonant frequencies. They work great as "beepers", but are very poor for general sound output. I would use cheap (dollar store) headphones or earbuds for testing...

EDIT: You were probably driving the piezo speaker at a frequency too low for it. They are not good at delivering low frequencies from such a small surface area (unless you use many of them in a phased array). They are GREAT at ultrasonic frequencies though.

[geekmaster]

The next obvious (but non-trivial) step is to write an ALSA driver for the K4 that can send sound out the accessory port, adding sound output capability to the K4.

For now (after mmatej provided the "proc" port to poke), I want to add K4 sound support using this method to my "geekmaster video player" in addition to the ALSA sound support used in my "noisy rhythms" demo program (thanks to twobob for giving me the push in the right direction).

Of course, my source code will give sound credit to twobob and mmatej.

[geekmaster]

Here is photo showing the accessory port pads on "older" K4s (like my K4):

Here is photo from amazon.com, showing the accessory port pads on a recent K4:

If they really did change the shape of those accessory "pads", that could potentially interfere with my idea to use magnets to attach speaker or headphone wires to them. Why would they DO that anyway?

[mmatej]

Originally Posted by geekmaster

Piezo earphones can be heard quite loudly driven by a germanium diode (1N34A or quivalent, as used in old "crystal set radios"). Perhaps your piezo speaker element wants 5 volts?

I would think that anything that can power an LED could surely drive earphones.

Also, piezo "speakers" are very frequency sensitive, with a small range of resonant frequencies. They work great as "beepers", but are very poor for general sound output. I would use cheap (dollar store) headphones or earbuds for testing...

EDIT: You were probably driving the piezo speaker at a frequency too low for it. They are not good at delivering low frequencies from such a small surface area (unless you use many of them in a phased array). They are GREAT at ultrasonic frequencies though.

I were not driving it at wrong frequency. No matter if I do

while true; do echo 0 > ${ac}; usleep 100; echo 1 > ${ac}; usleep 100; done;

or

while true; do echo 0 > ${ac}; echo 1 > ${ac}; done;

effect is the same. When I connect piezo to the oscillator, it works okay. I suspect there is some capacitor connected to the port in Kindle. If so, it would be hard to get higher frequencies out of the port.

New bad news: while writing this post I discovered I can hear ticks (about 5 per sec) on the piezo while the port is on. Also, I can hear eink updates clearly (try with while true; do eips -f ''; done) and I think wifi too! When I hold enter in the SSH, I can hear background noise.

[geekmaster]

Originally Posted by mmatej

I were not driving it at wrong frequency. No matter if I do

while true; do echo 0 > ${ac}; usleep 100; echo 1 > ${ac}; usleep 100; done;

or

while true; do echo 0 > ${ac}; echo 1 > ${ac}; done;

effect is the same. When I connect piezo to the oscillator, it works okay. I suspect there is some capacitor connected to the port in Kindle. If so, it would be hard to get higher frequencies out of the port.

New bad news: while writing this post I discovered I can hear ticks (about 5 per sec) on the piezo while the port is on. Also, I can hear eink updates clearly (try with while true; do eips -f ''; done) and I think wifi too! When I hold enter in the SSH, I can hear background noise.

The script probably has MUCH longer delays than those usleep calls, just in the echo commands. Proc ports often do not return from the echo until they are ready (depending on the device being "poked"). EDIT: In the new linux versions, "proc files" are now called "sysfs files", after they were moved from /proc to /sys.

You are probably driving it way below its resonant frequency. Although there may well be a filter capacitor on the output which could severely impede high frequencies. There may be an ioctl() call so a C program can go faster than writing to a proc file, but I did not find it (yet) in the gpl source code.

But the background noise you hear makes it seem like a filter capacitor is unlikely, so there is a good chance that we CAN switch it fast (even if we need to talk to it at a lower level such as direct GPIO output control using a custom device driver).

There is a HUGE difference between impossible and "almost impossible" (i.e. requiring heroic effort and/or OCD).

[mmatej]

Originally Posted by geekmaster

The script probably has MUCH longer delays than those usleep calls, just in the echo commands. Proc ports often do not return from the echo until they are ready (depending on the device being "poked"). EDIT: In the new linux versions, "proc files" are now called "sysfs files", after they were moved from /proc to /sys.

You are probably driving it way below its resonant frequency. Although there may well be a filter capacitor on the output which could severely impede high frequencies. There may be an ioctl() call so a C program can go faster than writing to a proc file, but I did not find it (yet) in the gpl source code.

But the background noise you hear makes it seem like a filter capacitor is unlikely, so there is a good chance that we CAN switch it fast (even if we need to talk to it at a lower level such as direct GPIO output control using a custom device driver).

There is a HUGE difference between impossible and "almost impossible" (i.e. requiring heroic effort and/or OCD).

Yup, maybe delays are bad. But what are that ticks? Tomorrow I'll try to connect it to speakers with amplifier to check if there are more voices. Somebody should probably connect the Kindle to the oscilloscope to chek that too.

[geekmaster]

Originally Posted by mmatej

Yup, maybe delays are bad. But what are that ticks? Tomorrow I'll try to connect it to speakers with amplifier to check if there are more voices. Somebody should probably connect the Kindle to the oscilloscope to check that too.

Noise on the accessory port is probably caused by voltage fluctuations due to varying load during wifi or 3G transmission (which draws a lot of power), during eink updates, and during other power-hungry events. For PWM output that could be clipped with a resistor and a pair of back-to-back diodes (or LEDs). The ticks might actually be your output. You can time how fast your code runs to see if it matches the tick rate. Like I said, it can take a long time to return from the echo statements, depending on how the device driver handles that sysfs (proc) interface to the accessory port.

[mmatej]

Originally Posted by geekmaster

Noise on the accessory port is probably caused by voltage fluctuations due to varying load during wifi or 3G transmission (which draws a lot of power), during eink updates, and during other power-hungry events. For PWM output that could be clipped with a resistor and a pair of back-to-back diodes (or LEDs). The ticks might actually be your output. You can time how fast your code runs to see if it matches the tick rate. Like I said, it can take a long time to return from the echo statements, depending on how the device driver handles that sysfs (proc) interface to the accessory port.

Strange they haven't connected any power stabilizer to the port. They must have known about it when they made it that way. Yes, external lamp does not need it, but... And about that ticks - there are not any output. They appear after enabling power on the port and after that it ticks with interval like 5/sec. Unfortunately, this spoils the attempt to make some data port out of it. I'll try to connect it to the counter to see if it counts that ticks (definitely yes, but to be sure). Then it would be needed to clean them. Not sure if it drops to 0V, but if not, it should be sufficient to move voltage level.

[geekmaster]

Originally Posted by mmatej

Strange they haven't connected any power stabilizer to the port. They must have known about it when they made it that way. Yes, external lamp does not need it, but... And about that ticks - there are not any output. They appear after enabling power on the port and after that it ticks with interval like 5/sec. Unfortunately, this spoils the attempt to make some data port out of it. I'll try to connect it to the counter to see if it counts that ticks (definitely yes, but to be sure). Then it would be needed to clean them. Not sure if it drops to 0V, but if not, it should be sufficient to move voltage level.

It is possible that the power is briefly turned off every 5 seconds to see if a it is plugged into a cradle with a battery charger or something. It is unclear in the source code because it looks like that code calls a USB charger an "accessory port" charger because most references are mixed into USB code.

You may be able to get rid of the ticks by loading a custom linux kernel from /mnt/us (which we can do with kexec, as shown in a thread). A custom kernel could also have direct port access to output reasonably useful audio on a K4.

[mmatej]

Originally Posted by geekmaster

It is possible that the power is briefly turned off every 5 seconds to see if a it is plugged into a cradle with a battery charger or something. It is unclear in the source code because it looks like that code calls a USB charger an "accessory port" charger because most references are mixed into USB code.

You may be able to get rid of the ticks by loading a custom linux kernel from /mnt/us (which we can do with kexec, as shown in a thread). A custom kernel could also have direct port access to output reasonably useful audio on a K4.

Can you tell me a reference to the code file where is it being controlled? I think for the real data output it would be necessary to implement data sending code in the kernel, because small delays would seriously damage output too, if one wanted to get high transfer rates.
Also, there are 5 ticks per second, not tick every 5 seconds.

[geekmaster]

Originally Posted by mmatej

Can you tell me a reference to the code file where is it being controlled? I think for the real data output it would be necessary to implement data sending code in the kernel, because small delays would seriously damage output too, if one wanted to get high transfer rates.
Also, there are 5 ticks per second, not tick every 5 seconds.

I searched the code for "ACCESSORY". It was found in a bunch of source modules. Most of it was mixed into USB code, and it controlled a voltage regulator ("Apollo" device?). It was not clear that this was the accessory port for LED reading lights. To see what I saw, just search the source code for "accessory" (without case matching).

[mmatej]

Originally Posted by geekmaster

I searched the code of "ACCESSORY". It was found in a bunch of source modules. Most of it was mixed into USB code, and it controlled a voltage regulator ("Apollo" device?). It was not clear that this was the accessory port for LED reading lights. To see what I saw, just search the source code for "accessory" (without case matching).

Thanks. Do yo know how to control LEDs using any similiar method?