Mic Interference :(

There is interference when recording from the mic. Recently I've been 
wondering if it is when the screen is updated or on or off.

Here is a dump of public domain (not that there much use.) recordings I 
have made: http://sutff.aross.me

Some are recorded in my computer room of interference doom, outside the 
house, in a school hall, on a walk, etc.

Some recordings are ok for 20secs then the interference kicks in :(.

I can upload more. In fact I think I have some that are a bit different 
from the ones I have uploaded. It's a start.

I have also tried experimenting with different sample rates. 200*-CD

Any thoughts please?

Ron K. Jeffries | 6 May 2013 03:03
Picon
Gravatar

Carabola

Uses MIPS, runs OpenWrt, a collection of useful peripheral interfaces.
One might assume you could choose to not include BLOBs for e.g. wi-fi.

To a non-specialist [moi...], it appears they are making a serious effort in direction of open hardware. This is not at teh level of a fully open FPGA based computer or an SOC derived from a design proven via FPGA.

This may be total junk. I' confident people will inform me of all that's wrong with it. ;)


p.s. I know very little about the company, nor am I affiliated in any way.
---
Ron K. Jeffries





<div><div dir="ltr">Uses MIPS, runs OpenWrt, a collection of useful peripheral interfaces.<div>One might assume you could choose to not include BLOBs for e.g. wi-fi.</div>
<div><br></div>
<div>To a non-specialist [moi...], it appears they are making a serious effort in direction of open hardware. This is not at teh level of a fully open FPGA based computer or an SOC derived from a design proven via FPGA.</div>
<div><br></div>
<div>This may be total junk. I' confident people will inform me of all that's wrong with it. ;)</div>
<div><br></div>
<div><a href="http://8devices.com/carambola-2">http://8devices.com/carambola-2</a></div>
<div><br></div>
<div>p.s. I know very little about the company, nor am I affiliated in any way.<br clear="all"><div>---<br>Ron K. Jeffries<div><br></div>
<div>
<br><br><br><br>
</div>
</div>
</div>
</div></div>
Werner Almesberger | 1 May 2013 19:15
Favicon
Gravatar

Statistics: April 2013

It's Worker's Day and time for the statistics department to do
some work:

IRC traffic on #qi-hardware and #milkymist:

http://downloads.qi-hardware.com/people/werner/stat/irc-qihw-0413.png

The mailing lists:

http://downloads.qi-hardware.com/people/werner/stat/ml-qihw-0413.png

The mailing lists maintained their usual level of traffic, with
a slight overall increase making April the busiest month of this
year so far. Qi-Hardware dropped a little while Milkymist saw
more activity. This resulted in Milkymist coming out on ahead of
Qi-Hardware, something that only happened three times within the
last year.

On IRC, things were relatively quiet, very similar to February.
This also ended the three months of continuous growth of
Milkymist IRC traffic.

- Werner

Werner Almesberger | 30 Apr 2013 02:14
Favicon
Gravatar

[RFC 0/3] ATBEN kernel support for the Ben NanoNote

For review before submitting things upstream:

This set of three patches adds support for the ATBEN IEEE 802.15.4 board,
along with the infrastructure needed for the Ben NanoNote. It consists
of three parts:

1) addition of a platform-specific reset function to the AT86RF230 driver.
   The driver assumes that it can reset the transceiver through a reset
   pin, but ATBEN uses power cycling instead. We therefore need a
   platform-specific function to perform the reset.

2) addition of an SPI-GPIO driver optimized for the Jz4740. ATBEN
   connects to a physical MMC interface but uses SPI (with some quirks)
   for communication. We therefore have to use bit-banging.

   The SPI-GPIO driver would be too slow, so we introduce a driver
   optimized for the Ingenic Jz4740 SoC that implements a subset of
   SPI-GPIO's functionality and is up to about six times faster.

3) last but not least, we add the platform definitions that connect
   the drivers and devices, and provide the platform-specific reset
   function. Since all this is specific to the Ben NanoNote, the code
   goes into arch/mips/jz4740/

Comments welcome.

- Werner

Why Is The Listener Package Not At Version 2?

Why is listener stuck at version 1.7.2 instead of version 2 alsa? I 
think I could make a easy action on loud noise script with v2.

I also have clap and whistle, detection and action apps off the WWW to 
try out.

I still have my existing goodies to upload... (this year or sooner!)

Ron K. Jeffries | 25 Apr 2013 17:25
Picon
Gravatar

Curious as to your thoughts re: Beaglebone Black

On balance,  Beaglebone Black appears (to me) to be an open platform that offers  good value ($45) with a nice balance of price/performance. Hardware design is open.

How interesting is it to you? I'm simply curious.

<div><div dir="ltr">On balance, &nbsp;Beaglebone Black appears (to me) to be an open platform that offers &nbsp;good value ($45) with a nice balance of price/performance. Hardware design is open.<div><br></div>
<div>How interesting is it to you? I'm simply curious.</div>
<div><br></div>
<div>
<a href="http://electronicdesign.com/microcontrollers/fast-low-power-module-runs-usb-connections">http://electronicdesign.com/microcontrollers/fast-low-power-module-runs-usb-connections</a><br clear="all"><div><br></div>
<div>Be well,</div>
<div>---</div>
<div>Ron K. Jeffries<br>
</div>
<div>
<div><br></div>
<div>
<br><br><br><br>
</div>
</div>
</div>
</div></div>
Werner Almesberger | 22 Apr 2013 15:36
Favicon
Gravatar

Ben NanoNote kernel, status of critical patches ?

Using the (nearly) mainline kernel (net-next, closely tracking 3.9),
one can almost build a working kernel for the Ben. "Working" here
means that it gets to a shell on the serial console.

In the OpenWRT build process, a fairly large number of kernel
patches gets applied. They live here:

http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/master/target/linux/xburst/patches-3.3

I found that just one of them is essential for getting the system to
boot:

0020-qi_lb60-NAND-add-data-partition.patch

I also used

0008-qi_lb60-Don-t-use-3-wire-spi-mode-for-the-display-fo.patch

to get fewer complaints from the kernel.

To boot a mainline kernel, I also had to override the boot command
line and add init=/etc/preinit (OpenWRT traditionally had a kernel
hack that added this directly to init/main.c, but I don't know if
they still use this. In any case, our u-boot setup seems to expect
the kernel to find preinit on its own, which it doesn't.)

With this, I get to a shell and can play with ATBEN and such.

Since I'm using a "headless" board, I don't know whether the screen
would actually work. The absence of

0007-Add-ili8960-lcd-driver.patch

in mainline suggests that it won't. Another thing that's missing
is the USB driver,

0002-Add-jz4740-udc-driver.patch

The rest of those 3.3 patches are mainly about NAND optimizations,
audio, power saving, wireless, and assorted minor changes.

I wonder what the status of all those patches is. Have they been
submitted towards upstream ? If yes, have they been accepted by
the respective subsystem maintainers and just haven't propagated
into Linus' tree yet ? Is someone tracking them ?

- Werner

Werner Almesberger | 10 Apr 2013 16:43
Favicon
Gravatar

Performance analysis of SPI drivers for ATBEN

[ Also posted on the linux-zigbee hardware list. No cross-post, since
  few people will be on both lists. ]

What this is all about
----------------------

The ATBEN board on the Ben NanoNote needs a bit-banging SPI driver.
There are several ways to implement this, ranging from reuse of the
generic spi-gpio driver to an optimized driver that's specific for
this platform.

I implemented several such approaches and measured their performance
in the Ben NanoNote. Below are my findings.

Comments welcome.

Cast and characters
-------------------

spi_atben_gpio: NanoNote-specific framework for setting up the
AT86RF230/1 with SPI-GPIO or one of the optimized drivers (below).
The name derives from spi_atben (see below) and should be changed
(maybe to atben_spi or atben_spi_gpio ?) since it is not an SPI
driver but merely a framework that provides configuration data and
performs miscellaneous platform setup.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/spi_atben_gpio.c

spi_atben: like spi_atben_gpio, but contains a highly optimized
SPI driver for the ATBEN configuration in the Ben NanoNote.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/spi_atben.c

spi-jz4740-gpio: SPI-GPIO driver optimized for the Jz4740. Uses the
optimized register accesses from spi_atben but pin assignment is not
restricted to ATBEN. The only limitation is that MOSI, MISO, and
SCLK must be on the same port.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/spi/spi-jz4740-gpio.c

spi-gpio-atben: task-specific SPI-GPIO driver using the #include
"spi-gpio.c" method. Replaces gpiolib functions with register
accesses specific to the ATBEN configuration in the Ben NanoNote.
Note that some of the code could be moved into Jz4740
architecture-specific GPIO support.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/spi/spi-gpio-atben.c

In the following sections, we abbreviate the stack configurations
as follows:

Abbreviation	Framework	Transport	Chip driver
---------------	---------------	---------------	-----------
spi-gpio	spi_atben_gpio	spi-gpio	at86rf230
spi-gpio-atben	spi_atben_gpio	spi-gpio-atben	at86rf230
spi-jz4740-gpio	spi_atben_gpio	spi-jz4740-gpio	at86rf230
spi_atben	spi_atben			at86rf230

Measurements
------------

Access time to AT86RF231 registers and buffer, in microseconds, on
an otherwise idle Ben NanoNote:

Driver		read from 0x51		read 120 bytes from buffer
|		|	write 0x0a to 0x15	write 1 byte to buffer (0x33)
|		|	|	read 1 byte from buffer	write 120 bytes
|		|	|	|	|	|	|
spi-gpio	 81	 85	186	1696	 97	1596
spi-gpio-atben	 63	 59	123	 498	 65	 437
spi-jz4740-gpio	 10	  8	 21	 280	 10	 231
spi_atben	 10	  7	 21	 280	 10	 230

Data rate for hypothetical buffer accesses of infinite length.
I.e., kbps = 1000*119*8/(t_write120-t_write1)

Driver		buffer read (kbps)	buffer write (kbps)
---------------	-----------------------	-------------------
spi-gpio	 630			 635			
spi-gpio-atben	2549			2559
spi-jz4740-gpio	3676			4308
spi_atben	3676			4327

At the air interface, IEEE 802.15.4 has a data rate of 250 kbps.
The AT86RF231 transceiver also supports non-standard higher data
rates up to 2 Mbps.

Driver(s)				Code size (lines)
---------------------------------------	-----------------
spi_atben_gpio				 128
spi_atben_gpio + spi-gpio-atben		 128+ 53
spi_atben_gpio + spi-jz4740-gpio	 128+416
spi_atben				 423

Computational cost
------------------

The high-level operations of sending and receiving produce the
following major low-level operations:

Operation	register	buffer		waitqueue
		read	write	read	write
---------------	-------	-------	-------	-------	---------
reception	1	-	1	-	1
transmission	9	4	-	1	1

Using the measured data from above, we get the following total
computational overhead in microseconds, without considering the
waitqueue scheduling delay:

Driver		reception		transmission
		1	120	127	1	120	125 (bytes)
---------------	-------	-------	-------	-------	-------	-------
spi-gpio	 267	1777	1866	1166	2665	2727
spi-gpio-atben	 186	 561	 583 	 868	1240	1256
spi-jz4740-gpio	  31	 290	 304 	 132	 353	 362

Note that the minimum frame length in IEEE 802.15.4 is 5 bytes.
The values for 125 (excluding CRC) and 127 (including CRC) bytes
are extrapolated.

According to [1], maximum-sized frames can be sent/received,
including CSMA/CA and acknowledgement, at a rate between one
every 4928 us and one every 7168 us.

We would therefore get the following maximum CPU load:

Driver		Reception	Transmission
---------------	---------------	------------
spi-gpio	38%		55%
spi-gpio-atben	12%		25%
spi-jz4740-gpio	 6%		 7%

Observations
------------

spi-gpio needs the smallest amount of new code but is also very
inefficient, making it questionable whether this configuration
would yield acceptable performance in regular use.

With spi-gpio-atben, only a small amount of code is added, but
buffer accesses become almost 4 times faster. Register reads and
writes are still fairly slow.

spi_atben and spi-jz4740-gpio both achieve the best performance
without significant differences between them. Both add a complete
SPI driver. Of the two, spi-jz4740-gpio is preferable, because it
uses the nearly universal spi_atben_gpio framework driver.

Conclusion
----------

I think performance trumps most other considerations in this case.
spi-gpio is clearly too inefficient. spi_atben_gpio with
spi-jz4740-gpio offers the best performance and has a low impact
on the system load (< 10%). In case this solution would be met
with strong resistance for some reason, spi-gpio-atben would offer
a compromise between performance and the amount of code.

References
----------

[1] http://www.jennic.com/files/support_files/JN-AN-1035%20Calculating%20802-15-4%20Data%20Rates-1v0.pdf

Werner Almesberger | 1 Apr 2013 22:35
Favicon
Gravatar

Statistics: March 2013

Just in - the latest data from the statistics department:

IRC traffic on #qi-hardware and #milkymist:

http://downloads.qi-hardware.com/people/werner/stat/irc-qihw-0313.png

The mailing lists:

http://downloads.qi-hardware.com/people/werner/stat/ml-qihw-0313.png

The mailing lists were fairly quiet, with Qi-Hardware showing a
slight increase from the low at the beginning of the year, with
Milkymist taking a late hibernation.

Meanwhile, both IRC channels saw more activity, with #qi-hardware
recovering largely from last month's drop and #milkymist adding a
third month of continuous growth.

- Werner

NN: Change Gamma?

I want to redshift the screen (Like http://jonls.dk/redshift/ does for 
X.) so I can more easily go to sleep or to not have my night adjusted 
eyes spoilt when using my NN. :)

Thanks again.

Set Brightness & Contrast?

I can't find any info. How does one change and/or set the brightness or 
the contrast of the frame buffer and the console?
Thanks.


Gmane