http://wirelessafrica.meraka.org.za/wiki/api.php?action=feedcontributions&user=Kingdavid&feedformat=atomWirelessAfrica - User contributions [en]2024-03-19T03:09:41ZUser contributionsMediaWiki 1.39.6http://wirelessafrica.meraka.org.za/wiki/index.php?title=DIY_Mesh_Guide_Software_and_Resources&diff=4863DIY Mesh Guide Software and Resources2011-12-07T07:22:28Z<p>Kingdavid: /* Resources */</p>
<hr />
<div>{|align="right"<br />
| style="height:100%;width:20em;border:1px solid #D9D9D9;background-color:#F2F2F2;" valign="top" |<br />
<br />
*[[DIY_Mesh_Guide|'''DIY Mesh Guide Home''']]<br />
*[[DIY_Mesh_Guide_Download|'''Download Guide''']]<br />
*[[DIY_Mesh_Guide_Feedback|'''Feedback Received''']]<br />
*[[DIY_Mesh_Guide_Software_and_Resources|'''Hardware & Software requirements and Resources''']]<br />
|}<br />
<br />
== Pilot mesh projects ==<br />
<br />
A number of pilot mesh projects across the world have demonstrated that a community can establish and maintain a wireless mesh network and have access to a range of modern information and communication services. Below are some of the examples mentioned in the guide.<br />
<br />
*[http://www.cuwireless.net/ Champaign-Urbana Community Wireless Network (CUWiN)]<br />
<br />
*[http://start.freifunk.net/ Freifunk.net] and [http://wiki.freifunk.net/Hauptseite Freifunk wiki site]<br />
<br />
*[http://www.tibtec.org/ Dharamsala Community Wireless Mesh Network]<br />
<br />
*[http://link.net.zm/ Linknet], Macha, Zambia<br />
<br />
*Peebles Valley in South Africa [[Mpumulanga Mesh]] and [http://www.fmfi.org.za/wiki/index.php/Mpumalanga_Mesh:Project_Overview First Mile First Inch (FMFI) Mpumalanga Mesh]<br />
<br />
==Hardware Required==<br />
<br />
Wireless routers: Linksys WRT54G (up to version 4.0) or Linksys WRT54GL (version 1.0 or 1.1). From WRT54G version 5.0 the flash memory has been reduced from 4MB to 2MB and as a result the memory is no longer sufficient for the Freifunk firmware. The Linksys WRT54GL is currently one of the most popular devices for wireless networking. <br />
<br />
Running old firmware on new hardware can hang up the router. You can check the [http://en.wikipedia.org/wiki/WRT54G Wikipedia Linksys page] for specifications of the different Linksys models and hardware revisions.<br />
<br />
==Software Required==<br />
<br />
The Freifunk and DD-WRT firmware is continually being updated and new releases are available on a regular basis. Always check for the latest versions online as the DIY Guide might not be updated regularly enough to reflect the newest versions of the firmware. <br />
<br />
* '''Freifunk firmware version x.x.x''' (The latest version of the firmware can be download from http://download-master.berlin.freifunk.net/ipkg/_g+gl/ ) If the full names of the files are not fully displayed, move the mouse over each name/link and notice the bottom left corner of your screen for the full name of the file. All these files are the same except for the language (i.e. English, German, etc.) they have been built for. To download the English version, select openwrt-g-freifunk-x.x.x-en.bin. Note the folder/directory to which this file is stored on your local machine. The firmware is continually being updated and revised. You can see the [http://download-master.berlin.freifunk.net/ipkg/readme.txt readme.txt] in the Freifunk packages directory for an explanation of the different firmware packages available.<br />
<br />
* '''DD-WRT firmware version x.x''' (download from http://www.dd-wrt.com/dd-wrtv2/downloads.php ) Select ''stable'' → select ''dd-wrt.vxx SP2'' → select ''standard'' → select ''dd-wrt.vxx_wrt54g.bin''<br />
<br />
* '''Putty.exe''' - This is a Windows SSH client, required for any PC/laptop running Windows (download from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html or other website on the internet)<br />
<br />
* '''Tcpdump''' (download the latest tcpdump and libpcap library from http://downloads.openwrt.org/whiterussian/packages/ ) <br />
<br />
* '''dot-draw''' (download the latest olsrd-mod-dot-draw package from http://downloads.openwrt.org/whiterussian/packages/ )<br />
<br />
==Resources==<br />
<br />
*[http://wire.less.dk/cantenna/ '''Video - Making a Cantenna'''] The video shows, step-by-step, the building of a cantenna (antenna made from a can) for wireless networking (Wi-Fi, WLAN at 2.4 Ghz). Without audio, and with simple subtitles and clear pantomimic instructions, the video lends itself well to localisation. <br />
<br />
*[http://wndw.net/download.html '''Wireless Networking in the Developing World'''] The overall goal of this book is to help you build affordable communication technology in your local community by making best use of whatever resources are available. Using inexpensive off-the-shelf equipment and local sources for materials and fabricating parts yourself, you can build reliable network links with very little budget. By working with your local community, you can build a telecommunications infrastructure that benefits everyone who participates in it.<br />
<br />
*[http://www.it46.se/voip4d/voip4d.php '''VoIP-4D Primer''' - Building Voice Infrastructure in Developing Regions] The guide explains the essentials of telephony use over the internet in developing countries. It also includes hands-on guidelines and configuration files as a background to building your own telephony system<br />
<br />
----<br />
Please report any broken links to '''diymeshguide[at]meraka.org.za'''</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=DIY_Mesh_Guide_Software_and_Resources&diff=4862DIY Mesh Guide Software and Resources2011-12-07T07:22:12Z<p>Kingdavid: /* Resources */</p>
<hr />
<div>{|align="right"<br />
| style="height:100%;width:20em;border:1px solid #D9D9D9;background-color:#F2F2F2;" valign="top" |<br />
<br />
*[[DIY_Mesh_Guide|'''DIY Mesh Guide Home''']]<br />
*[[DIY_Mesh_Guide_Download|'''Download Guide''']]<br />
*[[DIY_Mesh_Guide_Feedback|'''Feedback Received''']]<br />
*[[DIY_Mesh_Guide_Software_and_Resources|'''Hardware & Software requirements and Resources''']]<br />
|}<br />
<br />
== Pilot mesh projects ==<br />
<br />
A number of pilot mesh projects across the world have demonstrated that a community can establish and maintain a wireless mesh network and have access to a range of modern information and communication services. Below are some of the examples mentioned in the guide.<br />
<br />
*[http://www.cuwireless.net/ Champaign-Urbana Community Wireless Network (CUWiN)]<br />
<br />
*[http://start.freifunk.net/ Freifunk.net] and [http://wiki.freifunk.net/Hauptseite Freifunk wiki site]<br />
<br />
*[http://www.tibtec.org/ Dharamsala Community Wireless Mesh Network]<br />
<br />
*[http://link.net.zm/ Linknet], Macha, Zambia<br />
<br />
*Peebles Valley in South Africa [[Mpumulanga Mesh]] and [http://www.fmfi.org.za/wiki/index.php/Mpumalanga_Mesh:Project_Overview First Mile First Inch (FMFI) Mpumalanga Mesh]<br />
<br />
==Hardware Required==<br />
<br />
Wireless routers: Linksys WRT54G (up to version 4.0) or Linksys WRT54GL (version 1.0 or 1.1). From WRT54G version 5.0 the flash memory has been reduced from 4MB to 2MB and as a result the memory is no longer sufficient for the Freifunk firmware. The Linksys WRT54GL is currently one of the most popular devices for wireless networking. <br />
<br />
Running old firmware on new hardware can hang up the router. You can check the [http://en.wikipedia.org/wiki/WRT54G Wikipedia Linksys page] for specifications of the different Linksys models and hardware revisions.<br />
<br />
==Software Required==<br />
<br />
The Freifunk and DD-WRT firmware is continually being updated and new releases are available on a regular basis. Always check for the latest versions online as the DIY Guide might not be updated regularly enough to reflect the newest versions of the firmware. <br />
<br />
* '''Freifunk firmware version x.x.x''' (The latest version of the firmware can be download from http://download-master.berlin.freifunk.net/ipkg/_g+gl/ ) If the full names of the files are not fully displayed, move the mouse over each name/link and notice the bottom left corner of your screen for the full name of the file. All these files are the same except for the language (i.e. English, German, etc.) they have been built for. To download the English version, select openwrt-g-freifunk-x.x.x-en.bin. Note the folder/directory to which this file is stored on your local machine. The firmware is continually being updated and revised. You can see the [http://download-master.berlin.freifunk.net/ipkg/readme.txt readme.txt] in the Freifunk packages directory for an explanation of the different firmware packages available.<br />
<br />
* '''DD-WRT firmware version x.x''' (download from http://www.dd-wrt.com/dd-wrtv2/downloads.php ) Select ''stable'' → select ''dd-wrt.vxx SP2'' → select ''standard'' → select ''dd-wrt.vxx_wrt54g.bin''<br />
<br />
* '''Putty.exe''' - This is a Windows SSH client, required for any PC/laptop running Windows (download from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html or other website on the internet)<br />
<br />
* '''Tcpdump''' (download the latest tcpdump and libpcap library from http://downloads.openwrt.org/whiterussian/packages/ ) <br />
<br />
* '''dot-draw''' (download the latest olsrd-mod-dot-draw package from http://downloads.openwrt.org/whiterussian/packages/ )<br />
<br />
==Resources==<br />
<br />
*[http://wire.less.dk/cantenna/ '''Video - Making a Cantenna'''] The video shows, step-by-step, the building of a cantenna (antenna made from a can) for wireless networking (Wi-Fi, WLAN at 2.4 Ghz). Without audio, and with simple subtitles and clear pantomimic instructions, the video lends itself well to localisation. <br />
<br />
*[http://wndw.net/download.html '''Wireless Networking in the Developing World'''] The overall goal of this book is to help you build affordable communication technology in your local community by making best use of whatever resources are available. Using inexpensive off-the-shelf equipment and local sources for materials and fabricating parts yourself, you can build reliable network links with very little budget. By working with your local community, you can build a telecommunications infrastructure that benefits everyone who participates in it.<br />
<br />
*[hhttp://www.it46.se/voip4d/voip4d.php '''VoIP-4D Primer''' - Building Voice Infrastructure in Developing Regions] The guide explains the essentials of telephony use over the internet in developing countries. It also includes hands-on guidelines and configuration files as a background to building your own telephony system<br />
<br />
----<br />
Please report any broken links to '''diymeshguide[at]meraka.org.za'''</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=49-node_Indoor_Mesh&diff=485849-node Indoor Mesh2011-01-05T13:50:03Z<p>Kingdavid: </p>
<hr />
<div>== Manuals now available ==<br />
<br />
* [[Media:Meshlab_manual_freebsd.pdf|'''The old FreeBSD server manual in PDF format''']]<br />
* [[Media:Meshlab_manual_linux.pdf|'''The new Linux server manual in PDF format''']]<br />
<br />
==Introduction==<br />
Their are a plethora of mesh routing protocols being used worldwide today (See: [[Wireless Mesh Networking]]). Some of these have become popular due to organizations taking the trouble to convert the specification into usable code that can be run on a wireless router while other protocols remain purely academic and have only been run on computer simulations. There is also a new 802.11s working group which is seeking to create [[Mesh Standards]]. Protocols for which code is available will be run on the massive mesh, indoor testbed, which consists of a grid of 49 nodes (See 1st thumbnail image). Some code will also be ported to run on the massive mesh - for example HSLS is being ported to FreeBSD and Linux. Performance metrics will be gathered such as average throughput and latency together with their variance.<br />
<br />
[[Image:Massive-mesh-layout.jpg|thumb]]<br />
<br />
[[Mobility]] on wireless mesh networks is also a feature that we aim to test. One method of doing this is by using roaming nodes built onto robots like the [[Mesh Wanderer]] Lego robot shown in the 2nd picture. Each protocol is generally suited to different scenarios, some scale better to very large meshes due to less broadcast traffic others are better at handling mobility. Once all these metrics are gathered, better protocol choices can be made when a mesh network is built.<br />
<br />
[[Image:Robot00001-small.jpg|thumb]]<br />
<br />
The 3rd and 4th thumbnail images on the right show two scenarios represented by the [[OLSR Dot Draw]] visualization tool. The 3rd image shows mesh configuration with no omni antennas attached, while the 4th image shows mesh configuration with an omni attached to node 44.<br />
<br />
[[Image:Office-mesh-no-omni.jpg|thumb]]<br />
[[Image:Office-mesh-omni44.jpg|thumb]]<br />
<br />
Other visualization tools are also being worked on.<br />
<br />
==Operating Systems==<br />
The lab has been designed so that it is possible to network boot every node off a single server. This allows us to easily change the software running on the clients right down to the operating system level. The server runs on Linux but there is also an old legacy FreeBSD server that is still running and can be used. <br />
<br />
<br />
== Workshop notes from workshop held in August 2009 ==<br />
<br />
* [[Media:Lab_day1.pdf|'''Day 1 of workshop: Learning the lab tools''']]<br />
* [[Media:Lab_workshop_day2.pdf|'''Day 2 of workshop: The click modular router''']]<br />
<br />
<br />
=== Click tutorials ===<br />
<br />
==== Tutorial 1 ====<br />
<br />
Build a packet reflector which reflects all IP packets on a specific interface. So for example if I get a "ping echo" on the interface - send a "ping echo" back to the originating host on this interface. This will cause the other side to send a "ping echo reply" - which our reflector will also send back. You will notice this will cause ping to show (DUP) messages because it's getting duplicate echo reply's. This is also a fun trick if a hacker is trying to port scan you - he will get port scanned back - and get really upset and then leave the world of hacking and do something useful with his life like compose melodies for the limited repertoire of ocarina music.<br />
<br />
*[[Solution for Original Tutorial 1]]<br />
<br />
==== Tutorial 2 ====<br />
<br />
Create a "hello world" program which sends the string "Goodbye world" from one host to another host using UDP/IP. You will need to create a sender on one host and a receiver on the other host<br />
* [[Solution for tutorial 2 - sender]]<br />
* [[Solution for tutorial 2 - receiver]]<br />
<br />
==Steps to the Ultimate lab platform==<br />
<br />
''' Completed '''<br />
<br />
* In April 2009 the server was migrated to an Ubuntu hardy LTS based system and a large range of 2009 ubuntu filesystem images are available to run on the nodes<br />
* A 1 TB raid system was installed in the server to safeguard against data loss<br />
* In August 2009 we completed a scheduler which is only available on the internal LAN at the moment but will soon be available externally for researchers to schedule time in the lab<br />
* We have installed a touch screen in the building which will allow you to access information about the mesh lab<br />
<br />
''' We need to make some of these possible from a GUI - all of this is currently possible from the command line'''<br />
* Boot flash image on all nodes<br />
* Boot NFS filesystem image off server<br />
* Reboot row 1,2,3 ...<br />
* Command to send to all nodes <br />
* Console output of node xx<br />
* Console to set up traffic over network<br />
* Choose routing protocol to launch<br />
* Setup a set of measurements<br />
- Throughput<br />
- Delay<br />
- Packetloss<br />
* Graph of results – auto generate from gnuplot<br />
* Visualization panel – Graphviz – UCSB type visualization<br />
<br />
''' Demo experiments to make available from a web page '''<br />
* Start a video streaming experiment over the mesh and observe video degradation as mesh parameters are changed <br />
* Change the routing protocol, power levels, routing protocol parameters, start traffic sources, show graph results<br />
<br />
==Notes of things to fix==<br />
<br />
* The /export/ubuntu/ubuntu_hardy_click os has a problem with the wireless driver - it fails with large packets sizes ... eg ping -s 1500</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Gnu_Radio&diff=4857Gnu Radio2010-04-20T19:21:31Z<p>Kingdavid: /* Installing Gnuradio */</p>
<hr />
<div>== Purpose ==<br />
<br />
To trial a white spaces network in a rural area and learn what is possible<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Veljko Pejovic<br />
* Elizabeth Belding<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
<br />
==Technical notes==<br />
<br />
===Installing Gnuradio===<br />
* The main installation page (http://gnuradio.org/redmine/wiki/gnuradio/)<br />
* Building from source (http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide)<br />
* Ubuntu specific installation instructions (http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall)<br />
<br />
My notes for customization:<br />
./configure --prefix=/home/djohnson/gnuradio<br />
make<br />
make check<br />
make install<br />
This will install all the libraries and programs in /home/djohnson/gnuradio<br />
<br />
Add gnuradio python libraries to PYTHONPATH ... add to your ~/.bashrc or /etc/bash.basrc file<br />
export PYTHONPATH = /home/djohnson/gnuradio/lib/python2.6/site-packages<br />
<br />
== Useful links ==</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Gnu_Radio&diff=4856Gnu Radio2010-04-20T18:57:23Z<p>Kingdavid: /* Installing Gnuradio */</p>
<hr />
<div>== Purpose ==<br />
<br />
To trial a white spaces network in a rural area and learn what is possible<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Veljko Pejovic<br />
* Elizabeth Belding<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
<br />
==Technical notes==<br />
<br />
===Installing Gnuradio===<br />
* The main installation page (http://gnuradio.org/redmine/wiki/gnuradio/)<br />
* Ubuntu installation instructions (http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall)<br />
<br />
My notes for customization:<br />
./configure --prefix=/home/djohnson/gnuradio<br />
make<br />
make check<br />
make install<br />
This will install all the libraries and programs in /home/djohnson/gnuradio<br />
<br />
Add gnuradio python libraries to PYTHONPATH ... add to your ~/.bashrc or /etc/bash.basrc file<br />
export PYTHONPATH = /home/djohnson/gnuradio/lib/python2.6/site-packages<br />
<br />
== Useful links ==</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Gnu_Radio&diff=4855Gnu Radio2010-04-20T17:40:25Z<p>Kingdavid: /* Installing Gnuradio */</p>
<hr />
<div>== Purpose ==<br />
<br />
To trial a white spaces network in a rural area and learn what is possible<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Veljko Pejovic<br />
* Elizabeth Belding<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
<br />
==Technical notes==<br />
<br />
===Installing Gnuradio===<br />
* The main installation page (http://gnuradio.org/redmine/wiki/gnuradio/)<br />
* Ubuntu installation instructions (http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall)<br />
<br />
My notes for customization:<br />
./configure --prefix=/home/djohnson/gnuradio<br />
make<br />
make check<br />
make install<br />
<br />
This will install all the libraries and programs in /home/djohnson/gnuradio<br />
<br />
== Useful links ==</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Gnu_Radio&diff=4854Gnu Radio2010-04-20T17:10:05Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
To trial a white spaces network in a rural area and learn what is possible<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Veljko Pejovic<br />
* Elizabeth Belding<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
<br />
==Technical notes==<br />
<br />
===Installing Gnuradio===<br />
* The main installation page (http://gnuradio.org/redmine/wiki/gnuradio/)<br />
* Ubuntu installation instructions (http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall)<br />
<br />
<br />
== Useful links ==</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Gnu_Radio&diff=4853Gnu Radio2010-04-20T04:20:23Z<p>Kingdavid: New page: = Purpose == To trial a white spaces network in a rural area and learn what is possible == Team Members == * David Johnson * Veljko Pejovic * Elizabeth Belding ==Idea description== ...</p>
<hr />
<div>= Purpose ==<br />
<br />
To trial a white spaces network in a rural area and learn what is possible<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Veljko Pejovic<br />
* Elizabeth Belding<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
<br />
==Technical notes==<br />
<br />
===Installing Gnuradio===<br />
* The main installation page (http://gnuradio.org/redmine/wiki/gnuradio/)<br />
* Ubuntu installation instructions (http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall)<br />
<br />
<br />
== Useful links ==</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4852Macha Monitoring2010-04-10T00:20:10Z<p>Kingdavid: /* This to be put in a new section - academic writing guide */</p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
* To analyse flow rates trpr (http://pf.itd.nrl.navy.mil/protools/trpr.html)<br />
* Coralreef port analysis (http://learn.caida.org/cds/traffic0202/CoralReef/index.html)<br />
* CAida list of tools (http://www.caida.org/tools/)<br />
<br />
=== Understanding port numbers and other networky stuff ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
* TTLs set by various operating systems (http://members.cox.net/~ndav1/self_published/TTL_values.html)<br />
* Meaning of http codes (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)<br />
* Mime type descriptions (http://www.feedforall.com/mime-types.htm)<br />
* Why youtube can't be cached (http://tumbleweed.org.za/2009/02/18/fun-squid-and-cdns)<br />
<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)<br />
<br />
=== This to be put in a new section - academic writing guide ===<br />
* Writing style guide (http://elearning.homestead.com/ACADEMIC_WRITING_GUIDE.htm)<br />
* When to italicise (http://www.ehow.com/how_2049063_italicize-properly.html)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4851Macha Monitoring2010-04-09T23:35:40Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
* To analyse flow rates trpr (http://pf.itd.nrl.navy.mil/protools/trpr.html)<br />
* Coralreef port analysis (http://learn.caida.org/cds/traffic0202/CoralReef/index.html)<br />
* CAida list of tools (http://www.caida.org/tools/)<br />
<br />
=== Understanding port numbers and other networky stuff ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
* TTLs set by various operating systems (http://members.cox.net/~ndav1/self_published/TTL_values.html)<br />
* Meaning of http codes (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)<br />
* Mime type descriptions (http://www.feedforall.com/mime-types.htm)<br />
* Why youtube can't be cached (http://tumbleweed.org.za/2009/02/18/fun-squid-and-cdns)<br />
<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)<br />
<br />
=== This to be put in a new section - academic writing guide ===<br />
* Writing style guide (http://elearning.homestead.com/ACADEMIC_WRITING_GUIDE.htm)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4850Macha Monitoring2010-04-06T20:43:48Z<p>Kingdavid: /* Understanding port numbers and other networky stuff */</p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
* To analyse flow rates trpr (http://pf.itd.nrl.navy.mil/protools/trpr.html)<br />
* Coralreef port analysis (http://learn.caida.org/cds/traffic0202/CoralReef/index.html)<br />
* CAida list of tools (http://www.caida.org/tools/)<br />
<br />
=== Understanding port numbers and other networky stuff ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
* TTLs set by various operating systems (http://members.cox.net/~ndav1/self_published/TTL_values.html)<br />
* Meaning of http codes (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)<br />
* Mime type descriptions (http://www.feedforall.com/mime-types.htm)<br />
* Why youtube can't be cached (http://tumbleweed.org.za/2009/02/18/fun-squid-and-cdns)<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4849Macha Monitoring2010-03-23T22:18:13Z<p>Kingdavid: /* Understanding port numbers and other networky stuff */</p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
* To analyse flow rates trpr (http://pf.itd.nrl.navy.mil/protools/trpr.html)<br />
* Coralreef port analysis (http://learn.caida.org/cds/traffic0202/CoralReef/index.html)<br />
* CAida list of tools (http://www.caida.org/tools/)<br />
<br />
=== Understanding port numbers and other networky stuff ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
* TTLs set by various operating systems (http://members.cox.net/~ndav1/self_published/TTL_values.html)<br />
* Meaning of http codes (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)<br />
* Mime type descriptions (http://www.feedforall.com/mime-types.htm)<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4848Macha Monitoring2010-03-05T09:10:22Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
* To analyse flow rates trpr (http://pf.itd.nrl.navy.mil/protools/trpr.html)<br />
* Coralreef port analysis (http://learn.caida.org/cds/traffic0202/CoralReef/index.html)<br />
* CAida list of tools (http://www.caida.org/tools/)<br />
<br />
=== Understanding port numbers and other networky stuff ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
* TTLs set by various operating systems (http://members.cox.net/~ndav1/self_published/TTL_values.html)<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4847Macha Monitoring2010-03-05T08:33:45Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
* To analyse flow rates trpr (http://pf.itd.nrl.navy.mil/protools/trpr.html)<br />
* Coralreef port analysis (http://learn.caida.org/cds/traffic0202/CoralReef/index.html)<br />
<br />
=== Understanding port numbers and other networky stuff ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
* TTLs set by various operating systems (http://members.cox.net/~ndav1/self_published/TTL_values.html)<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4846Macha Monitoring2010-03-05T08:27:17Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
* To analyse flow rates trpr (http://pf.itd.nrl.navy.mil/protools/trpr.html)<br />
<br />
=== Understanding port numbers and other networky stuff ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
* TTLs set by various operating systems (http://members.cox.net/~ndav1/self_published/TTL_values.html)<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4845Macha Monitoring2010-03-04T22:53:42Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
<br />
=== Understanding port numbers and other networky stuff ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
* TTLs set by various operating systems (http://members.cox.net/~ndav1/self_published/TTL_values.html)<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4844Macha Monitoring2010-02-24T08:08:21Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
<br />
=== Understanding port numbers ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)<br />
* Meaning inside squid log files (http://www.linofee.org/~jel/proxy/Squid/accesslog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4843Macha Monitoring2010-02-17T06:48:57Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
* Port number assignments (http://www.iana.org/assignments/port-numbers)<br />
<br />
=== Understanding port numbers ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4842Macha Monitoring2010-02-17T05:08:40Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
<br />
=== Understanding port numbers ===<br />
* Database of known official and unofficial port numbers being used (http://ports.tantalo.net/?q=gnutella)<br />
<br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4841Macha Monitoring2010-02-16T23:41:54Z<p>Kingdavid: /* Scraping tcpdump files */</p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
To analyse packet size distribution:L tcpdstat -w out.log <tracefile><br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4840Macha Monitoring2010-02-16T23:05:32Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)<br />
* Hit rate for proxy server (http://www.squid-cache.org/Scripts/)<br />
* Squid analysis (http://squid-graph.securlogic.com/)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4839Macha Monitoring2010-02-16T22:56:49Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Monitoring tools ===<br />
* tshark<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
* ipsumdump<br />
* tcpflow<br />
* tcpdstat -d <tracefile><br />
<br />
=== DNS analysis ===<br />
* Macha uses dnsmasq (uses a default of only 150 names in the cache)<br />
dnsmasq -c --cache-size=<cachesize> <br />
- if cachesize=0 it disables it<br />
<br />
=== Checking reboot commands issued ===<br />
* Check with<br />
last reboot<br />
<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4838Macha Monitoring2010-02-16T22:43:42Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Scraping tcpdump files ===<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)<br />
<br />
=== Squid proxy analysis ===<br />
* Description of meaning of all log files (http://www.tenon.com/support/webten/papers/squidlog.shtml)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4837Macha Monitoring2010-02-15T05:06:54Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
* Examples using pypcap<br />
* Pyscan logger (http://code.activestate.com/recipes/576690/)<br />
* Packet monitoring with dpkt (http://code.activestate.com/recipes/576678/)<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Scraping tcpdump files ===<br />
<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4836Macha Monitoring2010-02-14T07:11:04Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
==Changes made on machines in Macha to enable monitoring==<br />
<br />
==Tools installed on my machine for analysis==<br />
<br />
===Python tools fro analysing tcpdump files or live interface===<br />
* pypcap<br />
sudo apt-get install python-pypcap<br />
dpkg --listfiles python-pypcap ... to see files that it installes<br />
svn checkout http://dpkt.googlecode.com/svn/trunk/ dpkt-read-only<br />
cd dpkt-read-only<br />
sudo make install<br />
cd /usr/share/doc/python-pypcap/examples<br />
python test.py<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Scraping tcpdump files ===<br />
<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4835Macha Monitoring2010-02-13T01:06:30Z<p>Kingdavid: </p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Scraping tcpdump files ===<br />
<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)<br />
* TCPdump tips - filters can also be used with pcapy (http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)<br />
* Crawdad has tools but mostly looks like wifi specific (http://crawdad.cs.dartmouth.edu/tools.php)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Macha_Monitoring&diff=4834Macha Monitoring2010-02-13T00:31:22Z<p>Kingdavid: New page: == Purpose == Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usag...</p>
<hr />
<div>== Purpose ==<br />
<br />
<br />
Rural wireless networks in developing regions often depend on slow satellite links for their Internet access. This paper will try to quanitify the traffic patterns and usage of a slow satellite internet link in a rural wireless network and compare this to recent studies of Internet uisage patterns in the developed world to understand key challenges. This will be used as a starting point for further work to try and optimize Internet usage over slow satellite links in developing regions.<br />
<br />
== Team Members ==<br />
<br />
* David Johnson<br />
* Elizabeth Belding<br />
* Kevin Almeroth<br />
* Gertjan van Stam<br />
<br />
<br />
==Idea description==<br />
<br />
<br />
<br />
==Main challenges==<br />
<br />
<br />
<br />
==Milestones==<br />
<br />
<br />
==Primary obstacles==<br />
<br />
==Evaluation==<br />
<br />
=== Metrics that will be measured === <br />
<br />
* Percentage of local traffic<br />
* Caching efficiency (ratio of incoming traffic to external destination to outgoing traffic to external destination)<br />
* DNS hit rate<br />
* DNS delays (can be quite significant) , % of DNS hit on local DNS<br />
* Up/Down Traffic usage over a 2 week loggin interval<br />
* Flow analysis<br />
- TCP connection durations<br />
- Number of simultaneous flows in the network over time<br />
- Plot of bandwidth used per IP source address in the network - check if there are clear dominant users<br />
- # Retransmissions<br />
- TCP round trip times for ACKS<br />
* Breakdown of application classes using port numbers<br />
- Peer-to-peer traffic<br />
- Web<br />
- video streaming ... protocols like RTSP have there own port - also IP based for flash sites like youtube<br />
- VoIP ... prototocols like SIP and some known Skype ports - Skype is a challenge if using port 80<br />
- Instant messaging ... could catch things like IRC but maybe IP addresses based again<br />
- tunneling<br />
<br />
== Useful links ==<br />
<br />
=== Scraping tcpdump files ===<br />
<br />
* List of useful tools (http://www.comlab.uni-rostock.de/research/tools.html)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Solution_for_tutorial_2_-_receiver&diff=4833Solution for tutorial 2 - receiver2010-01-12T21:04:19Z<p>Kingdavid: </p>
<hr />
<div> define ($DEV ath0)<br />
<br />
FromDevice($DEV)<br />
->c :: Classifier(12/0800)<br />
// Strip off all the ethernet, IP and UDP headers<br />
->Strip(42)<br />
->Print(CONTENTS ASCII)<br />
->Discard</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Solution_for_tutorial_2_-_receiver&diff=4832Solution for tutorial 2 - receiver2010-01-12T21:03:45Z<p>Kingdavid: New page: define ($DEV ath0) FromDevice($DEV) ->c :: Classifier(12/0800) // Strip off all the ethernet, IP and UDP headers ->Strip(42) ->Print(CONTENTS ASCII) ->Discard</p>
<hr />
<div> define ($DEV ath0)<br />
<br />
FromDevice($DEV)<br />
->c :: Classifier(12/0800)<br />
// Strip off all the ethernet, IP and UDP headers<br />
->Strip(42)<br />
->Print(CONTENTS ASCII)<br />
->Discard</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Solution_for_tutorial_2_-_sender&diff=4831Solution for tutorial 2 - sender2010-01-12T21:02:45Z<p>Kingdavid: New page: Change the $SRC and $DST to suite the IP addresses of your nodes define($DEV ath0, $SRC 172.30.1.74, $DST 172.30.1.75) InfiniteSource("Goodbye World", 1 ) ->UDPIPEncap($SRC, 4001, ...</p>
<hr />
<div> Change the $SRC and $DST to suite the IP addresses of your nodes<br />
<br />
define($DEV ath0, $SRC 172.30.1.74, $DST 172.30.1.75)<br />
<br />
InfiniteSource("Goodbye World", 1 )<br />
->UDPIPEncap($SRC, 4001, $DST, 4002)<br />
->IPPrint("my packet")<br />
->arpq :: ARPQuerier($DEV)<br />
->q :: Queue<br />
->ToDevice($DEV)<br />
<br />
FromDevice($DEV)<br />
-> c :: Classifier(12/0806 20/0002)<br />
-> [1] arpq<br />
<br />
arpq[1] -> q</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Solution_for_Original_Tutorial_1&diff=4830Solution for Original Tutorial 12010-01-12T21:01:40Z<p>Kingdavid: New page: define($DEV ath0) FromDevice($DEV) -> c :: Classifier(12/0800, 12/0806 20/0002) -> CheckIPHeader(14) -> IPMirror -> StripToNetworkHeader -> GetIPAddress(16) // Paint the dest...</p>
<hr />
<div> define($DEV ath0)<br />
<br />
FromDevice($DEV)<br />
-> c :: Classifier(12/0800, 12/0806 20/0002)<br />
-> CheckIPHeader(14)<br />
-> IPMirror<br />
-> StripToNetworkHeader<br />
-> GetIPAddress(16) // Paint the destination IP address<br />
-> arpq :: ARPQuerier($DEV)<br />
-> IPPrint<br />
-> q :: Queue<br />
-> ToDevice($DEV)<br />
<br />
arpq[1] -> q;<br />
c[1] -> [1] arpq;</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=49-node_Indoor_Mesh&diff=482949-node Indoor Mesh2010-01-12T21:01:07Z<p>Kingdavid: </p>
<hr />
<div>== Manuals now available ==<br />
<br />
* [[Media:Meshlab_manual_freebsd.pdf|'''The old FreeBSD server manual in PDF format''']]<br />
* [[Media:Meshlab_manual_linux.pdf|'''The new Linux server manual in PDF format''']]<br />
<br />
==Introduction==<br />
Their are a plethora of mesh routing protocols being used worldwide today (See: [[Wireless Mesh Networking]]). Some of these have become popular due to organizations taking the trouble to convert the specification into usable code that can be run on a wireless router while other protocols remain purely academic and have only been run on computer simulations. There is also a new 802.11s working group which is seeking to create [[Mesh Standards]]. Protocols for which code is available will be run on the massive mesh, indoor testbed, which consists of a grid of 49 nodes (See 1st thumbnail image). Some code will also be ported to run on the massive mesh - for example HSLS is being ported to FreeBSD and Linux. Performance metrics will be gathered such as average throughput and latency together with their variance.<br />
<br />
[[Image:Massive-mesh-layout.jpg|thumb]]<br />
<br />
[[Mobility]] on wireless mesh networks is also a feature that we aim to test. One method of doing this is by using roaming nodes built onto robots like the [[Mesh Wanderer]] Lego robot shown in the 2nd picture. Each protocol is generally suited to different scenarios, some scale better to very large meshes due to less broadcast traffic others are better at handling mobility. Once all these metrics are gathered, better protocol choices can be made when a mesh network is built.<br />
<br />
[[Image:Robot00001-small.jpg|thumb]]<br />
<br />
The 3rd and 4th thumbnail images on the right show two scenarios represented by the [[OLSR Dot Draw]] visualization tool. The 3rd image shows mesh configuration with no omni antennas attached, while the 4th image shows mesh configuration with an omni attached to node 44.<br />
<br />
[[Image:Office-mesh-no-omni.jpg|thumb]]<br />
[[Image:Office-mesh-omni44.jpg|thumb]]<br />
<br />
Other visualization tools are also being worked on.<br />
<br />
==Operating Systems==<br />
The lab has been designed so that it is possible to network boot every node off a single server. This allows us to easily change the software running on the clients right down to the operating system level. The server runs on Linux but there is also an old legacy FreeBSD server that is still running and can be used. <br />
<br />
<br />
== Workshop notes from workshop held in August 2009 ==<br />
<br />
* [[Media:Lab_day1.pdf|'''Day 1 of workshop: Learning the lab tools''']]<br />
* [[Media:Lab_workshop_day2.pdf|'''Day 2 of workshop: The click modular router''']]<br />
<br />
<br />
=== Click tutorials ===<br />
<br />
==== Tutorial 1 ====<br />
<br />
Build a packet reflector which reflects all IP packets on a specific interface. So for example if I get a "ping echo" on the interface - send a "ping echo" back to the originating host on this interface. This will cause the other side to send a "ping echo reply" - which our reflector will also send back. You will notice this will cause ping to show (DUP) messages because it's getting duplicate echo reply's. This is also a fun trick if a hacker is trying to port scan you - he will get port scanned back - and get really upset and then leave the world of hacking and do something useful with his life like compose melodies for the limited repertoire of ocarina music.<br />
<br />
*[[Solution for Original Tutorial 1]]<br />
<br />
==== Tutorial 2 ====<br />
<br />
Create a "hello world" program which sends the string "Goodbye world" from one host to another host using UDP/IP. You will need to create a sender on one host and a receiver on the other host<br />
* [[Solution for tutorial 2 - sender]]<br />
* [[Solution for tutorial 2 - receiver]]<br />
<br />
==Steps to the Ultimate lab platform==<br />
<br />
''' Completed '''<br />
<br />
* In April 2009 the server was migrated to an Ubuntu hardy LTS based system and a large range of 2009 ubuntu filesystem images are available to run on the nodes<br />
* A 1 TB raid system was installed in the server to safeguard against data loss<br />
* In August 2009 we completed a scheduler which is only available on the internal LAN at the moment but will soon be available externally for researchers to schedule time in the lab<br />
* We have installed a touch screen in the building which will allow you to access information about the mesh lab<br />
<br />
''' We need to make some of these possible from a GUI - all of this is currently possible from the command line'''<br />
* Boot flash image on all nodes<br />
* Boot NFS filesystem image off server<br />
* Reboot row 1,2,3 ...<br />
* Command to send to all nodes <br />
* Console output of node xx<br />
* Console to set up traffic over network<br />
* Choose routing protocol to launch<br />
* Setup a set of measurements<br />
- Throughput<br />
- Delay<br />
- Packetloss<br />
* Graph of results – auto generate from gnuplot<br />
* Visualization panel – Graphviz – UCSB type visualization<br />
<br />
''' Demo experiments to make available from a web page '''<br />
* Start a video streaming experiment over the mesh and observe video degradation as mesh parameters are changed <br />
* Change the routing protocol, power levels, routing protocol parameters, start traffic sources, show graph results</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4828Music Coach2009-12-06T05:34:01Z<p>Kingdavid: /* Academic references */</p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some code segments of the [http://www.antcom.de/gtick/ GTick] open source software can be used for this.<br />
<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called [http://www.musescore.org/ Musescore] could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)<br />
<br />
=== MIDI importing ===<br />
* C++ MIDI Library (http://www.jdkoftinoff.com/main/Free_Projects/C++_MIDI_Library/)<br />
* The Computer Music Project Software (http://www.cs.cmu.edu/~music/music.software.html)<br />
* Very Simple MIDI parsing code (http://cap-lore.com/EnglishSuites/code/code.html)<br />
<br />
=== MIDI file format explanation ===<br />
* David's MIDI Spec (http://www.srm.com/qtma/davidsmidispec.html)<br />
<br />
<br />
=== Notation software ===<br />
* GUIDOLib qt music notation library (http://guidolib.sourceforge.net/)<br />
<br />
=== Companies that have done music reconigtion ===<br />
* WIDI 1998-2009 Recognition System (79$ stadard, $159 professional) (http://www.widisoft.com/english/mp3-midi-products.html)<br />
* Shazam iphone song reconigtion (http://www.shazam.com/music/web/pages/getshazam.html)<br />
<br />
=== Academic references ===<br />
* Google scholar results for "transcription of musical sound" (http://scholar.google.com/scholar?hl=en&q=transcription+of+musical+sound&btnG=Search&as_sdt=2000&as_ylo=&as_vis=0)<br />
* Bibliography on automatic music transcription (http://www.recognisoft.com/cgi-bin/main.cgi?id=62&lan=en&n=&p=&d=&o=&r=y&s=)<br />
<br />
===Instrument Ranges ===<br />
* Of all orchestral instruments (http://www.orchestralibrary.com/reftables/rang.html)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4827Music Coach2009-12-05T09:07:23Z<p>Kingdavid: /* Useful links */</p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some code segments of the [http://www.antcom.de/gtick/ GTick] open source software can be used for this.<br />
<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called [http://www.musescore.org/ Musescore] could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)<br />
<br />
=== MIDI importing ===<br />
* C++ MIDI Library (http://www.jdkoftinoff.com/main/Free_Projects/C++_MIDI_Library/)<br />
* The Computer Music Project Software (http://www.cs.cmu.edu/~music/music.software.html)<br />
* Very Simple MIDI parsing code (http://cap-lore.com/EnglishSuites/code/code.html)<br />
<br />
=== MIDI file format explanation ===<br />
* David's MIDI Spec (http://www.srm.com/qtma/davidsmidispec.html)<br />
<br />
<br />
=== Notation software ===<br />
* GUIDOLib qt music notation library (http://guidolib.sourceforge.net/)<br />
<br />
=== Companies that have done music reconigtion ===<br />
* WIDI 1998-2009 Recognition System (79$ stadard, $159 professional) (http://www.widisoft.com/english/mp3-midi-products.html)<br />
* Shazam iphone song reconigtion (http://www.shazam.com/music/web/pages/getshazam.html)<br />
<br />
=== Academic references ===<br />
* Google scholar results for "transcription of musical sound" (http://scholar.google.com/scholar?hl=en&q=transcription+of+musical+sound&btnG=Search&as_sdt=2000&as_ylo=&as_vis=0)<br />
<br />
===Instrument Ranges ===<br />
* Of all orchestral instruments (http://www.orchestralibrary.com/reftables/rang.html)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4826Music Coach2009-12-05T07:09:09Z<p>Kingdavid: /* Companies that have done music reconigtion */</p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some code segments of the [http://www.antcom.de/gtick/ GTick] open source software can be used for this.<br />
<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called [http://www.musescore.org/ Musescore] could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)<br />
<br />
=== MIDI importing ===<br />
* C++ MIDI Library (http://www.jdkoftinoff.com/main/Free_Projects/C++_MIDI_Library/)<br />
* The Computer Music Project Software (http://www.cs.cmu.edu/~music/music.software.html)<br />
* Very Simple MIDI parsing code (http://cap-lore.com/EnglishSuites/code/code.html)<br />
<br />
=== MIDI file format explanation ===<br />
* David's MIDI Spec (http://www.srm.com/qtma/davidsmidispec.html)<br />
<br />
<br />
=== Notation software ===<br />
* GUIDOLib qt music notation library (http://guidolib.sourceforge.net/)<br />
<br />
=== Companies that have done music reconigtion ===<br />
* WIDI 1998-2009 Recognition System (79$ stadard, $159 professional) (http://www.widisoft.com/english/mp3-midi-products.html)<br />
* Shazam iphone song reconigtion (http://www.shazam.com/music/web/pages/getshazam.html)<br />
<br />
=== Academic references ===<br />
* Google scholar results for "transcription of musical sound" (http://scholar.google.com/scholar?hl=en&q=transcription+of+musical+sound&btnG=Search&as_sdt=2000&as_ylo=&as_vis=0)<br />
*</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4825Music Coach2009-12-05T07:01:08Z<p>Kingdavid: /* Useful links */</p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some code segments of the [http://www.antcom.de/gtick/ GTick] open source software can be used for this.<br />
<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called [http://www.musescore.org/ Musescore] could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)<br />
<br />
=== MIDI importing ===<br />
* C++ MIDI Library (http://www.jdkoftinoff.com/main/Free_Projects/C++_MIDI_Library/)<br />
* The Computer Music Project Software (http://www.cs.cmu.edu/~music/music.software.html)<br />
* Very Simple MIDI parsing code (http://cap-lore.com/EnglishSuites/code/code.html)<br />
<br />
=== MIDI file format explanation ===<br />
* David's MIDI Spec (http://www.srm.com/qtma/davidsmidispec.html)<br />
<br />
<br />
=== Notation software ===<br />
* GUIDOLib qt music notation library (http://guidolib.sourceforge.net/)<br />
<br />
=== Companies that have done music reconigtion ===<br />
* WIDI Recognition System (79$ stadard, $159 professional) (http://www.widisoft.com/english/mp3-midi-products.html)<br />
* Shazam iphone song reconigtion (http://www.shazam.com/music/web/pages/getshazam.html)<br />
<br />
<br />
=== Academic references ===<br />
* Google scholar results for "transcription of musical sound" (http://scholar.google.com/scholar?hl=en&q=transcription+of+musical+sound&btnG=Search&as_sdt=2000&as_ylo=&as_vis=0)<br />
*</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4824Music Coach2009-12-04T18:24:06Z<p>Kingdavid: /* Useful links */</p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some code segments of the [http://www.antcom.de/gtick/ GTick] open source software can be used for this.<br />
<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called [http://www.musescore.org/ Musescore] could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)<br />
<br />
=== MIDI importing ===<br />
* C++ MIDI Library (http://www.jdkoftinoff.com/main/Free_Projects/C++_MIDI_Library/)<br />
* The Computer Music Project Software (http://www.cs.cmu.edu/~music/music.software.html)<br />
* Very Simple MIDI parsing code (http://cap-lore.com/EnglishSuites/code/code.html)<br />
<br />
=== MIDI file format explanation ===<br />
* David's MIDI Spec (http://www.srm.com/qtma/davidsmidispec.html)<br />
<br />
<br />
=== Notation software ===<br />
* GUIDOLib qt music notation library (http://guidolib.sourceforge.net/)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4823Music Coach2009-11-18T18:22:37Z<p>Kingdavid: /* Useful links */</p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some code segments of the [http://www.antcom.de/gtick/ GTick] open source software can be used for this.<br />
<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called [http://www.musescore.org/ Musescore] could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)<br />
<br />
=== MIDI importing ===<br />
* C++ MIDI Library (http://www.jdkoftinoff.com/main/Free_Projects/C++_MIDI_Library/)<br />
* The Computer Music Project Software (http://www.cs.cmu.edu/~music/music.software.html)<br />
* Very Simple MIDI parsing code (http://cap-lore.com/EnglishSuites/code/code.html)<br />
<br />
=== MIDI file format explanation ===<br />
* David's MIDI Spec (http://www.srm.com/qtma/davidsmidispec.html)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4822Music Coach2009-11-18T04:32:53Z<p>Kingdavid: /* Useful links */</p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some code segments of the [http://www.antcom.de/gtick/ GTick] open source software can be used for this.<br />
<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called [http://www.musescore.org/ Musescore] could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)<br />
<br />
=== MIDI importing ===<br />
* C++ MIDI Library (http://www.jdkoftinoff.com/main/Free_Projects/C++_MIDI_Library/)<br />
* The Computer Music Project Software (http://www.cs.cmu.edu/~music/music.software.html)<br />
* Very Simple MIDI parsing code (http://cap-lore.com/EnglishSuites/code/code.html)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4821Music Coach2009-11-16T17:53:53Z<p>Kingdavid: /* Code that can be used */</p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some code segments of the [http://www.antcom.de/gtick/ GTick] open source software can be used for this.<br />
<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called [http://www.musescore.org/ Musescore] could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4820Music Coach2009-11-16T17:51:50Z<p>Kingdavid: </p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some pieces of the GTick open source software can be used for this.<br />
<br />
[[Image:Gtick.jpg]]<br />
<br />
* To display notes on the screen a very well written qt application called musescore could provide some useful code segments<br />
<br />
<br />
[[Image:Musescore.jpg]]<br />
<br />
<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.coExamplem/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=File:Gtick.jpg&diff=4819File:Gtick.jpg2009-11-16T17:49:45Z<p>Kingdavid: </p>
<hr />
<div></div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=File:Musescore.jpg&diff=4818File:Musescore.jpg2009-11-16T17:49:27Z<p>Kingdavid: </p>
<hr />
<div></div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4817Music Coach2009-11-16T17:49:03Z<p>Kingdavid: </p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
==Code that can be used==<br />
* A metronome with visual and audio feedback will be very useful for a player to know the pace that the application is expecting you to play the music - some pieces of the GTick open source software can be used for this.<br />
<br />
<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.com/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4816Music Coach2009-11-10T00:59:16Z<p>Kingdavid: </p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.com/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)<br />
* Smart phones as instruments (http://www.cnn.com/2009/TECH/10/15/iphone.music.zoozbeat/index.html)<br />
* Zoozbeat (http://www.youtube.com/watch?v=YEsC-lklOA4)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4815Music Coach2009-11-10T00:47:03Z<p>Kingdavid: </p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.com/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)<br />
<br />
=== Accelerometer ===<br />
* Using accelerometer trace to detect shaking (http://msdn.microsoft.com/en-us/magazine/ee413721.aspx)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4814Music Coach2009-11-08T08:53:24Z<p>Kingdavid: </p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
==Using pulseaudio==<br />
* possible command<br />
pacat --record | sox -t raw -r 44100 -s -L -b 16 -c 2 - "output.wav"<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.com/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4813Music Coach2009-11-08T06:00:16Z<p>Kingdavid: </p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
* Most stable FFT system - fftw (http://www.fftw.org/)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.com/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4812Music Coach2009-11-08T05:59:04Z<p>Kingdavid: </p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)<br />
* Maemo 5 uses pulseaudio (http://www.pulseaudio.org)<br />
* Examples of using pulseaudio - parec (http://grangerx.wordpress.com/2009/08/03/fedora-11-recording-audio-from-pulseaudio-using-parec-and-sox/)</div>Kingdavidhttp://wirelessafrica.meraka.org.za/wiki/index.php?title=Music_Coach&diff=4811Music Coach2009-11-08T05:09:34Z<p>Kingdavid: </p>
<hr />
<div>== Requirements ==<br />
<br />
Submit (via email) a tentative project proposal, including: team member names, brief description of project (a paragraph or so), the main technical challenges, milestones/tasks to accomplish this, the primary obstacles/concerns, how you propose to evaluate the outcome.<br />
<br />
== Team Memebers ==<br />
* David Johnson<br />
* Dianna Han<br />
<br />
==Idea description==<br />
<br />
Use the Nokia N900 as a music coach which can check if you are playing a note at the correct pitch, check if a note is played at the correct time and optionally may allow you to display sheet music from midi files as well as control the pace of performance with movements of the body. It will act both as a real time feedback mechanism alerting you of pitch and rhythm inaccuracies as you play the notes and give you an overall evaluation at the end of your performance. The pitch evaluation is especially useful for instruments which don't have discrete notes such as a cello, violin, trombone or even human voice whereas the rhythm evaluation is suitable for all instruments. Other additional features such as an instrument tuner and a metronome could be added with trivial software modification. It should also be possible to evaluate only pitch with no pre-loaded music score by checking how close a note is to its nearest discrete note. This would assume an advanced student that is playing notes with less than a quarter tone of inaccuracy or else it would rounding to a note which is different to the original intended note. <br />
<br />
Different feedback mechanisms will be explored. Visual feedback could use a compass like display where North and South represent a pitch that is above or below the correct note and the length of the arrow represents the fractional difference between the notes. East and West represents whether you played the note too early or too late and the length of a second arrow also represents the fractional difference. Audio feedback could also be explored by playing the correct note on the speaker in the case of a pre-loaded score and using beats in the note which get closer together the further the note is away from the correct note. This would be ideal as a training module for someone learning scales on a cello, for example.<br />
<br />
One problem with a pre-loaded score is making allowances for musical expressiveness. This comes in the form of slowing down and speeding up your performance in sections of the music as well as adding vibrato to a note in the case of stringed instruments and the human voice. A vibrato note is an oscillation which falls slightly below and slightly above a note. The accelerometer could be used to sense rhythm by monitoring swaying movements on the body, if the phone was strapped onto a person. For example if the phone was strapped to the head, faster rocking movements in the head would speed up the performance and slower rocking movements would slow the performance down. Allowing for vibrato can be done by calculating the average pitch of the performed note over a specific time window.<br />
<br />
==Main challenges==<br />
# Real-time processing of the audio input to recognise the frequency of a note.<br />
# Different instruments have a range of timbre with transient harmonics which can dominate the fundamental frequency momentarily - the challenge will be to decide on an optimal time window to use for the pitch recognition. This challenge may simply limit the scope of instruments to ones which have a dominant fundamental from the attack to the decay of the note.<br />
# Real-time feedback display. You want the performer to get feedback as quickly as possible for it to be useful but if this is too soon - it may be inaccurate, whereas if its too late it will be more accurate but less useful.<br />
# If time permits, inferring rhythm from a trace of accelerometer inputs should not require the user to make movements of the body that would be unnatural. A gentle rocking of the head should be all that's required to alter the pace at which the pre-loaded music progresses.<br />
<br />
==Milestones==<br />
<br />
# Test some FFT code on a PC which can take as input - sample rate, number of bins and display the frequency of a single note on the screen<br />
# Run some experiments which compare time from note attack to display vs note accuracy.<br />
# Make use of some existing software which can read in a midi file and display the notes and reformat this for a Nokia N900 screen size.<br />
# Experiment with comparing a midi file to a live performance in terms of pitch accuracy - find optimal time windows for calculating average pitch of performed note. <br />
# Evaluate the accuracy of the attack and release times of the live performance with the start and stop times of the notes in the midi file. Make use of a metronome on the phone for the user to synchronise their performance.<br />
# Write a graphical interface on the Maemo simulator which creates feedback on the pitch and timing accuracy of the performance using a compass like display - (other more creative graphical displays may be developed). Also display momentary Pitch and timing accuracy as well as cumulative accuracy as a percentage. <br />
# If both the compass display and the midi file are to be displayed, then a blend of these two could be explored<br />
# Test the FFT code for pitch recognition on the N900<br />
# Test the midi file input on the N900<br />
# Test the graphical feedback display on the N900<br />
# Time permitting add the option to change the speed of the performance using the accelerometer<br />
<br />
==Primary obstacles==<br />
* Processing capability to carry out a real-time FFT. If the on-board CPU is not sufficient we might need to use the DSP which adds an extra level of complexity to the problem<br />
* Allowing for a certain level of musical expressiveness in a performance and not seeing this as pitch or rhythm inaccuracy. <br />
* Inferring rhythm for small subtle movements of the phone when attached to the body depends on accuracy of accelerometer.<br />
<br />
==Evaluation==<br />
* The real-time pitch recognition software on the N900 can be compared against some more accurate non-real time pitch recognition on a standard PC.<br />
* Musician's feedback on whether the device was useful in improving accuracy of performance.<br />
<br />
<br />
== Useful links ==<br />
<br />
=== Pitch recognition ===<br />
<br />
* http://www.nicholson.com/rhn/dsp.html<br />
* http://www.hotpaw.com/intuna/singintuna.readme.html<br />
* http://cs.ucsb.edu/~davidj/Files/thesis1995.pdf<br />
<br />
=== FFT ===<br />
* FFT on a symbian phone (http://wiki.forum.nokia.com/index.php/FFT_algorithm)<br />
<br />
=== Multimedia system Maemo 5 ===<br />
* Maemo 5 multimedia domain (http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Subsystem)</div>Kingdavid