#ekiga irc channel chat log

Here's a bit of conversation about Ekiga on Beagleboard that happened today.

(10:59:26 AM) Michelle: Hello!
(10:59:50 AM) Michelle: Anyone have Ekiga working on a Beagleboard?
(11:02:41 AM) johanbr [~j@JBrannlund2.MathStat.Dal.Ca] entered the room.
(11:17:44 AM) Snark: Abraxas3d, someone proposed patches recently for arm support, if I remember well
(11:19:33 AM) Snark: https://bugzilla.gnome.org/show_bug.cgi?id=611308
(11:19:46 AM) Snark: ^^^ that was that bug
(11:22:29 AM) Michelle: That looks promising - I'm still in the process of figuring out what is most likely causing Ekiga to crash. Is there any way I can help with getting Ekiga working on ARM?
(11:24:32 AM) Michelle: Do I take these attachments and add them to my source for ptlib and ekiga, to try them out?
(11:25:19 AM) Michelle: they look like scripts, to me.
(11:25:51 AM) Snark: they are patches
(11:26:03 AM) Snark: notice that they only add support for video
(11:26:15 AM) Snark: which would imply the rest is already working properly
(11:26:45 AM) ced117 [~ced117@AStrasbourg-157-1-11-114.w90-40.abo.wanadoo.fr] entered the room.
(11:35:17 AM) Michelle: Segmentation faults are all I seem to be getting so far. The beagleboard "ideas" website described Ekiga as "already compiled for the arm-7 on Angstrom (Angstrom being the OS). So The project would be to optimize it for the Beagle (and probably some debugging as Ekiga on beagle apparently is not that stable)." When I read this entry on the table of Beagleboard Ideas (from 2009), I took it to mean that a large part of or almost all of the work was probably done. The stability problems appear on beagleboard various forums - people that were able to get it running experience crashes and other setbacks.
(11:36:10 AM) Michelle: I'm optimistic it's well within striking range, if not already solved. I've just not had a lot of luck finding the magic recipe or thing I'm missing.
(11:36:19 AM) Michelle: the link to the bug report is very helpful!
(11:36:42 AM) Michelle: at the very least, encouraging.
(11:43:38 AM) Snark: if you can get traces, that would help find bugs
(11:44:10 AM) Snark: http://wiki.ekiga.org/index.php/Debugging_Ekiga
(11:44:16 AM) Snark: ^ explanations how to debug
(11:45:39 AM) Michelle: I do indeed have some traces, and have that link marked for reference. I don't want to waste anyone's time with traces that are due to trivial problems on my end, so I haven't submitted any quite yet.
(11:50:34 AM) Snark: ok
(11:50:48 AM) Snark: does the fact that parts of ekiga come as plugins help?
(11:53:13 AM) [L] [~iruan@dyn128-54-240-70.ucsd.edu] entered the room.
(11:53:35 AM) Michelle: I confess I don't know enough about plugins (other than the basic programming theory) in Ekiga to know if it helps or hurts. When installing, there is a directory of plugins, and they are populated. If there is a missing plugin, I would probably not be able to tell without being better oriented to using and installing plugins.
(11:54:45 AM) Michelle: I'll do my best to check, though.
(11:54:57 AM) Snark: which plugins are enabled?
(11:55:07 AM) Snark: they should all be optional things
(11:55:18 AM) Snark: so removing them to remove their problems could be an idea
(11:59:47 AM) Michelle: none currently installed in the release considered stable from Angstrom (3.2.0), and I'm still working through the rebuild-from-source for 3.2.6. I do remember seeing plugins on the last attempt, and will try your idea when it rebuilds. I appreciate the advice very much.
(12:02:11 PM) Snark: 3.2.0 had some crashes here and there, which have been fixed since

Ekiga crashing on Beagleboard

I have revision B7 Beagleboards (TI OMAP processor, which has an ARM Cortex A8 CPU).

I'm running Angstrom, and Ekiga was obtained from the software repository. I'm very interested in using Ekiga for an amateur radio project.

Ekiga crashes, though, and I'm trying to figure out why. I'm hoping one of you out there has already traveled this path, and might be able to point out where I'm going wrong.

I ran dbg following the instructions at http://wiki.ekiga.org/index.php/Debugging_Ekiga, and got the following.

Program received signal SIGSEGV, Segmentation fault.
0x4000ac6c in ?? () from /lib/ld-linux.so.3

The full file created by gdb is here:
http://microwaveengineeringproject.blogspot.com/2010/02/gdb-results-for-ekiga-on-beagleboard.html

I know that ld-linux.so.* libraries find and load the shared libraries needed by a program, get the program ready to run, and then run it. I saw that Ekiga needed ptlib and libopal. These libraries are installed, along with their -dbg versions for gdb, and -dev version

I'm confident Ekiga should work on the Beagleboard because I found this photograph by Koen on Flickr.

http://www.flickr.com/photos/koenkooi/3208840095/

gdb Results for Ekiga on Beagleboard

michelle@beagleboard:~$ more gdb-ekiga.txt
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-angstrom-linux-gnueabi"...
(no debugging symbols found)
(gdb) run
Starting program: /usr/bin/ekiga -d 4
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x4000ac6c in ?? () from /lib/ld-linux.so.3
(gdb) thread apply all bt
(gdb) quit
The program is running. Exit anyway? (y or n)
michelle@beagleboard:~$

Six-Port Device Notes

HSMM report 6 Feb 2010

Greetings MEPsters,

Today I was able to configure two WRT54GLs running OpenWRT. One was an access point with a wired connection to the internet, and the other was configured as a bridge. Beagleboards were attached to both of the WRT54GLs, and I could ping from both of them.

Here is a whiteboard block diagram of how these routers are configured.

http://www.flickr.com/photos/w5nyv/4332411901/

If that's too small (sorry about the white balance) then try this larger image.

http://www.flickr.com/photos/w5nyv/4332411901/sizes/l/

Today, I watched a webinar about High-Speed Multimedia Webinar. I noticed the webinar at the last minute - otherwise I would have mentioned it earlier.

Here's the writeup about it.

-=-=-=-=-=-=-=-

HSMM-MESH(tm) Networking Seminar

The HSMM-MESH(tm) Networking Seminar will cover all aspects of the HSMM-MESH
software developed in Austin, TX. The Webinar will begin with an explanation of
High-Speed Multi-Media (HSMM) and the subset of this topic which uses modified
Linksys WRT54GL 2.4 GHz Wireless Routers to form a mesh network, handy for high
speed digital communications in the ham band - for emergencies, special events
and field day.

The Webinar will cover applications, antennas, hardware, and the software. You
will learn how to load the software and how to configure it.

In the second part there will be a lab where we will actually load the software
into a router and configure the router. You will need a Linksys WRT54GL (any
version) or a WRT54G (Version 1.1 through 4 - version 5 or higher
will NOT work.)

The Webinar will be online at 8:00am Central time to give you a chance to get
logged in and test your setup before something starts happening. Training
starts at 9:00am with 10 minute breaks about every hour. And we will finish
in the afternoon after a lunch break.

You should Register before Saturday morning if possible. . If you have a
microphone and headset you will be able to ask questions verbally over VOIP.
Otherwise you can type in questions to be able to interact with the speaker.

The Webinar is provided through the courtesy of Ham-Com and is presented by
members of the NTMS-HSMM and Austin-HSMM groups. (contact...@kdream.com)
hsmm-mesh.org

-=-=-=-=-=-=-=-

There was a third part. Some of the third part was recorded by Jordan Cronin, and those recordings (he warned the quality might not be as good as he would like) can be found here:

http://qik.com/jordancronin

The seminar introduced HSMM and gave specific examples of its use in public service events. The configuration of their specific build of OpenWRT followed.

Read more about HSMM-MESH here:
http://www.hsmm-mesh.org/

For our application, I think there is a wrinkle with the HSMM-MESH software. On the hsmm-mesh site, I read the following passage.

"One feature of OLSR is called the "dynamic default gateway". When a node has internet access, as verified by periodic pings of various internet servers, it tells its neighbors that internet is available and the surrounding nodes will use this node as its default gateway. This is how every node gains internet access even if only one of them is connected to the internet. It still works if multiple nodes have direct internet access, but its behavior in this mode is not well tested. Sporadic internet access such as web browsing should handle this well. However, connections intended to be continuous, like streaming media, will definitely come to a halt if internet access switches from one node to another. This is because the IP address that you are accessing the internet from just changed and the far end will close the connection, as it should."

This sounds like that video streams would be interrupted? In our case, maybe we should investigate mobile IP? There is an RFC for mobile IP over IPv6, located here:

http://www.ietf.org/rfc/rfc3775.txt

I have this printed out and have plans to read it. There is another RFC for IPv4 as well. It's located here:

http://www.ietf.org/rfc/rfc3220.txt

The OLSR RFC can be found here:

http://www.ietf.org/rfc/rfc3626.txt

If you're lost in RFCs, then take heart - I am too!

What I'd like to do is get some sort of feeling as to what we'd have to add (if anything) to a build like OpenWRT in order to turn wireless routers into MEP prototypes.

The next step for the WRT54GLs here is to send video, with the source coming from USB webcams.


-Michelle W5NYV

Weekly Report 1 Feb 2010 - 5 Feb 2010

Hello everyone!

We're putting two Rev B beagleboards together with Linksys routers (WRT54GLs running OpenWRT) and experimenting with that combination for mobile MEPs. This is 2.4 GHz instead of our desired 3.4/5.8GHz full duplex plan, but will allow for easier and cheaper development of the software on the TI OMAP. This is much closer to the HSMM model of MEP than the custom-hardware model of MEP. While some progress has been made on hardware, I'd like to experiment with a solution that is more off-the-shelf. For one thing, the cost is quite competitive. A WRT54GL is $60. A Beagleboard is #149. USB to Ethernet conversion cable ranges in price from $10 to $25, depending on speed.

USB is not the best interface for our application, but it is the interface available on a stock beagleboard. However, there is an improvement available. The BeagleBuddy Zippy Ethernet Combo Board is an $80 expansion board for the BeagleBoard that adds the following:

* Battery Backed RTC
* Second MMC slot
* 10BaseT Ethernet
* Second RS-232
* +5V level I2C
* AT24 EEPROM

This eliminates USB in the path to the router. We have one Zippy board here at the lab, currently used on a project to set up a spectrum survey for 70cm.

Revision 5 of the test code tutorial for the NEON processor was released, and this revision is a candidate for the final version of the document. It can be found here:
http://www.delmarnorth.com/microwave/requirements/testcodetutorial_neon-test_draft5.pdf

It's also in the RSS feed, so it will automagically appear in your feed reader if you have subscribed to the project feed.

Next step is to add NEON support to Fastest Fourier Tranform in the West library. This project will improve signal processing on the beagleboard.

For further reading and reference, here are some web pages for the devices and software mentioned today.

Fastest Fourier Tranform in the West: http://www.fftw.org/

BeagleBuddy Zippy: http://www.tincantools.com/product.php?productid=16147&cat=249&page=1

Beagleboard Home Page: http://beagleboard.org/

WRT54GL router: http://en.wikipedia.org/wiki/Linksys_WRT54G_series#WRT54GL

OpenWRT: http://www.openwrt.org/

More soon,
-Michelle W5NYV

Neon-test Test Code Tutorial Draft 5

Here is draft 5 of the neon test code tutorial, for review and critique.