Monday, December 28, 2009

MakerBotWatch i really like it

posted by Mike Szczys
filed under:
arduino hacks

If you didn’t get the geeky watch you wanted for Christmas you should consider building yourself a MakerBotWatch. The watch is an Arduino, using an ATmega328 microcontroller running the bootloader. The watch has two concentric circles of LEDs for minutes and hours. A vertical row of four LEDs adds in the additional resolution needed to get 60 minutes on the watch face.

The schematic and board layout are available from an SVN repository so you can make your own board. The device will go into production as a kit but currently the laser-cut bezel will not be part of it.

[via Adafruit]

Wednesday, December 16, 2009

WTF

בשעות האחרנות נסיתי לעשות
apt-get update
זה פשוט מטורף התמונה אומרת הכול

ב השוואה ל חול

Monday, December 14, 2009

COS

Plug the Computer-On-a-Stick™ (COS) into your PC or Laptop and instantly transform your old environment
into a new and powerful secure workstation – without software installation!
􀀹 Use the COS when your PC or Laptop’s existing OS slows to a crawl or simply fails.
􀀹 Use the COS to create and edit Windows-compatible files & documents. Works with Microsoft Word, Excel,
PowerPoint, Paint, and more…
􀀹 View and create Adobe PDF files
􀀹 Retains your own customized desktop settings, address book, or bookmarks each time you plug into a
different host PC.
􀀹 Significantly reduce exposure to viruses, worms and spyware.
􀀹 Connect to remote PCs or servers with secure connectivity tools, including VNC, SSH and RDP.
Operation
1. Insert the mini CD into your PC or Laptop’s CD-ROM drive.
2. Insert the COS into any available USB Port.
3. Restart your Computer. When your system starts, set your login password (optional).
4. Have Fun!
Features
• High Speed Access (USB 2.0)
• Startup complete typically within 40 seconds
• Shutdown in seconds
• Configure to boot direct from USB drive without CD on many newer systems
• Non-volatile Flash memory. Write-protected OS
• Compressed utility optimizes use of space and reduces the risk of unauthorized modifications
• No hard disk needed
Software Specifications
• Linux 2.6.x Series Kernel
• Gnome Graphical User Interface Desktop
• Mozilla Firefox Web Browser
􀀹 OpenOffice Productivity Suite, including
􀀹 OpenOffice Writer for Word Processing
􀀹 OpenOffice Calc for Spreadsheets
􀀹 OpenOffice Draw for Vector Drawings
􀀹 OpenOffice Impress for Slideshow Presentations
• Evolution Email
• GAIM Instant Messaging Client - compatible with MSN Messenger, Yahoo IM, AIM, ICQ, and more.
• Remote SSH Access Applications (SSHFS, VNC, RDP)
• PDF Creator & Viewer
• Automatic Network Configuration - DHCP
• PPP Stack enabling Dial-out Option
Minimum System Requirements
• One USB port (USB 2.0 recommended)
• A BIOS supporting CD-ROM or direct USB boot option
• Any x86 CPU, keyboard and mouse
• 128Mb of RAM or more
• A monitor supporting 1024x768 pixel resolution

FingerGear™ Computer-On-a-Stick™

GONE JUST GONE



A Lute of my boosts just gone deleted Google or blogspot !! WTF

P2P Bandwidth Throttling in Israel, Legal and Technological Aspects

Written By: under Categories: File Sharing and Tags: Tags: , , , , , , , , , ,

0. Abstract
Do Israeli Internet Service Providers throttle, delay or block peer-to-peer traffic? This question has been spreading in Israeli forums and file-sharing networks, and has introduced theories from attempts to sell enhanced Internet packages to copyright infringement monitoring. This research, which was conducted between April and September 2009, was meant to check whether the claim was true. Using simple free tools we decided to inspect the legality of DPI and traffic shaping in Israel and whether it exists.

Our findings were that there is direct and deliberate interference in P2P traffic by at least 2 out of the 3 major ISPs and that this interference exists by both P2P caching and P2P blocking. The tests, conducted by independent volunteers, were directed by myself and with the assistance of Ynet’s staff, who published a Hebrew summary.
1. Background:
Peer-to-peer (P2P) file transfer protocols have been in common use since the advent of networked computing, but their rising profile (as well as the controversy surrounding them) began with the introduction of P2P sharing of copyrighted materials. Initially used for sharing small music files and applications, P2P today is a legitimate and widely used system for the distribution of any electronic media, and multiple gigabyte files are commonly shared amongst users from around the world. Whilst some researches imply that there is a slight decrease in the growth of P2P (Allot, 2009), P2P is still the Killer Internet Application, responsible for 21% of the Average Mobile Traffic Cell and in charge of an estimate of 70% (ReadWriteWeb, 2006.12.06) of the global Internet traffic during 2006, accounting for around 25% on some networks (PlusNet, 2008.07.17), but according to more detailed reports, accounting for more than 50% of the network’s traffic (ipoQue, 2009, TorrentFreak 2009.02.18).

Peer to Peer traffic consists of illegal downloads of files, voice over IP calls, instant messaging and other decentralized communication. The element common to all P2P services is the lack of economical benefit to the ISP from the client’s use of P2P. According to recent studies, P2P users consume more traffic (Arstechnica, 2008.07.04), and when traffic caps are used Internet Service Providers (ISPs) benefit and earn more from P2P use (Arstechnica, 2008.05.07).
Since 2007, claims that Israeli ISPs are blocking P2P traffic have been spread all over the Israeli Web. More recently, a report by Vuze Inc, a popular service utilizing P2P in order to provide its users with high definition video content over the BitTorrent protocol found that all three major Israeli ISPs block P2P traffic to some degree . (8.13% for Smile012, 18.51% for Bezeqint and 14.06% for Netvision). During 2009, complaints against the three major Israeli ISPs (inspected in our research) were brought to the media and were dismissed by the ISPs. Bezeq International claimed that it does not interfere with P2P traffic and called the claims ‘baseless’ (Ynet, 2009.03.29), whereas a year earlier it claimed that it is the only company that does not block P2P (Ynet, 2007.12.05 ). Smile012 dismissed Torrentleech’s claims that it blocks P2P traffic (Ynet, 2008.01.24, Torrentleech FAQ) and Netvision-Barak dismissed the claim that it de-prioritizes P2P traffic, claiming that such activity was impossible, and were it possible, it would block all child-pornography and offensive content (Ynet, 2007.05.27). However, and even though such formal announcements were made, many reports on informal conversations with customer support representatives who have acknowledged the problem. Another recent report was that Bezeq International was actually amending .torrent files in order to add the Bezeq International Tracker and save on outbound bandwidth (Torrentfreak, 2009.04.19 ); However, Bezeq International’s CEO rejected the claim and stated to Amitai Ziv, from TheMarker that “I will not operate an illegal video library on my servers, even if my competitors do that” (TheMarker, 2009.08.05).
For example, a person claiming to be an ex-Netvision customer support representative claims that they block P2P traffic originating outside of Israel (BGU Forum, 2009.03.26 ), an informal and anonymous executive in one of Israel’s ISPs stated that due to excessive outbound traffic costs, ISPs block P2P traffic (Haaretz, 2008.05.06 ); however, until now there was no extensive research to inspect any of these claims.

1.1 Legal framework
Israeli ISPs operate under a specific license which requires them (Israel has 39 licensees, 2009 numbers, general license example) Clause 5.4.1 to the general license states that the License Holder’s activity shall not interfere with the free competition in the telecom market or harm the public interest. Moreover, clause 29 to the Israeli Telecommunication Act (1982) specifies that interfering or blocking of electronic communication over a public network is a criminal ofence. Therefore, even without any net-neutrality regulation (see, for example, Tal Zarsky’s 2009 lecture during the ISOC conference ), Israel has the appropriate regulation to interfere with attempts to prioritize network packets and to withhold other packets.

Recent letters from the Telecommunication Ministry’s CEO (CEO Letter, 2009.07.15) explicitly stated to all telecom providers to avoid interfering with all traffic and especially Skype (TheMarker 2009.07.15); whilst some ISPs claim otherwise and state that there is no legal obligation for network neutrality (Themarker 2009.07.27), Our belief is that under the current legal status, without prior explicit consent by the End-User, network neutrality must be imposed at the strictest form in order to ensure impunity from liability for End-Users’ file sharing (MGM v. Grokster). The Israeli draft for the Electronic Commerce Act (Government Bills, 2008.01.14) exempts ISPs from Caching if they had not modified the packets (Clause 9). Moreover, Clauses 7-10 exempt liability if, and only if, the ISP had not manipulated any packet.

Moreover, Deep Packet Inspection (DPI) as executed by several of the Israeli ISPs, may be considered illegal wiretapping, as it is defined in the Israeli Wiretapping Act, as “Listening to another person’s conversation, interception or copying of another person’s conversation, and all with an apparatus”; DPI may also be considered Interfering with Computer Data under theComputer Act or illegal entry to computer information. DPI occurs when an apparatus listens to the End-Users’ packets, inspects their content and according to their content manipulates them or passes them to their destination. Unlike regular routing, that only “reads” the target address and sends the packet to its destination, DPI manipulates the packet, without the End-Users’ explicit consent and may be considered illegal. The Israeli Courts continuously ruled that inspecting one’s traffic and personal files consists as a crime under the Computer Act (CA 1126/06 Lerman v. State, where Lerman installed a Trojan horse; C 40206/06 State v. Pilosof). In Pilosof, the District Court of Tel-Aviv ruled that “Inspecting the Email message in the electronic range should be made with a broad perspective on the email’s traffic from its dispatch until its arrival to its destination, therefore, intercepting a message on the ISP’s computer is “real time” interception whilst the data is transferred and prior to the termination of computer communication (…) Accepting the state’s view might lead to an unwanted result where the ISP may not be prohibited from copying and reading the messages intended for his clients, as the intrusion occurs on his computers”.

Therefore, while traffic manipulation may inflict liability on ISPs when they manipulate traffic knowingly that such traffic is copyright infringing (even if manipulation means slowing down), we believe that it is illegal for Israeli ISPs to manipulate traffic.

1.2 Comcast’s FCC ruling.
Unlike Israel, the US struggle for network neutrality and against file sharing throttling began in the early 2000s (Tim Wu: Network Neutrality, Broadband Discrimination ) and has been brought to the attention of the FCC, which ruled that its role is to preserve the open nature of the Internet (FCC 2005 ). However, only in 2008, after Comcast, the 2nd largest ISP in the US was caughtthrottling P2P traffic (Gigaom 2008.07.11 ), the FCC had to examine whether blocking (or delaying) P2P traffic was in accordance with US regulation.

The FCC’s ruling (FCC, 2008 ) stated that Comcast may not limit or delay any peer to peer traffic, claiming that it was unlawful intervention in competition and against the public interest: “This practice is not “minimally intrusive” but invasive and outright discriminatory. Comcast admits that it interferes with about ten percent of uploading peer-to-peer TCP connections, and independent evidence shows that Comcast’s interference may be even more prevalent. In a test of over a thousand networks over the course of more than a million machine-hours, Vuze found that the peer-to-peer TCP connections of Comcast customers were interrupted more consistently and more persistently than those of any other provider’s customers. Similarly, independent evidence suggests that Comcast may have interfered with forty if not seventy-five percent of all such connections in certain communities” (…) “On its face, Comcast’s interference with peer-to-peer protocols appears to contravene the federal policy of “[promoting] the continued development of the Internet” because that interference impedes consumers from “[running] applications . . . of their choice,” rather than those favored by Comcast, and that interference limits consumers’ ability “to access the lawful Internet content of their choice,” including the video programming made available by vendors like Vuze. Comcast’s selective interference also appears to discourage the “development of technologies” — such as peer-to-peer technologies — that “maximize user control over what information is received by individuals . .. who use the Internet” because that interference (again) impedes consumers from “run[ning] applications . . . of their choice,” rather than those favoured by Comcast”.

The question now is whether Israeli ISPs do limit or even block traffic (where the delaying of packets equals blocking, see Comcast Ruling, pp. 26-27) and whether the Israeli regulator interferes with such activity. Moreover, as Israel has an oligopoly of three ISPs with no actual competition (further aggravated by a duopoly of Network Service Providers in Bezeq and Hot), there may be a case for antitrust inquries and not only inquries by the Telecommunication ministry.

2. The Test

In order to examine whether P2P traffic was blocked, we began the experiment with two tools developed by other parties. The first is the open-source Switzerland tool, developed by the EFF. “Switzerland is an open source, command-line software tool designed to detect the modification or injection of packets of data by ISPs. Switzerland detects changes made by software tools believed to be in use by ISPs such as Sandvine and AudibleMagic, advertising systems like FairEagle, and various censorship systems. Although currently intended for use by technically sophisticated Internet users, development plans aim to make the tool increasingly easy to use” (EFF, 2008). Switzerland was released following the FCC ruling and was the tool that the EFF used in order to prove the claim that Comcast was indeed throttling P2P traffic (TorrentFreak, 2008 ).

We also used Glasnost, which is partially supported by Google and the Max Planck Institute. Glastnost is a part of Measurement Labs and is an independent java client, running within a browser. Prior to our inspection, Glasnost found that Israeli ISPs are not throttling traffic. In its report, only 3 out of 971 tests were blocked, and out of 17 different ISPs measured in Israel, only 3 blocked P2P. However, these results do not include throttling or shaping. Therefore, we began our experiment without any additional Information.
2.1 EFF’s Switzerland
While we were unable to review the Switzerland logs, mostly due to our failure to coordinate between volunteers’ time to run the scripts, Switzerland assisted us in finding some interesting conclusions. We left a server to seed a .torrent file of a public domain video; our volunteers downloaded and uploaded the file again and again, looking for potential interference by the ISP or RST packets. We were unable to produce any substantial results or conclusions regarding traffic, mostly due to Switzerland’s interface.

However, after a massive number of attempts, we found out that another user is seeding our torrent, from the IP address 212.235.15.36 and not from the libTorrent Client we used (screenshot, screenshot ). We found a mention of such IP address in an Israeli Hardware forum describing it as one of Netvision’s caching servers (HWZone, 2009). While the IP address is associated with Netvision, we were able to authenticate that a similar IP address is being used in eMule caching (img src) and that 212.235.x.x, which was used in other conversations, are owned by Netvision (whois data). While this is not throttling with user packets, it is considered a severe interference with communication privacy and may be considered intercepting private conversations.

We believe that additional research is required to authenticate whether such activity is taking place in additional ISPs and whether this ISP is caching additional files. Moreover, such caching has severely tampered with our ability to inspect bandwidth throttling, as our inspection of speed was irrelevant once the .torrent and the file were cached on the ISP level.

We also encountered a strange download from a cTorrent download from 213.174.157.6 (screenshot), where we could find slight affiliation with IP addresses that are affiliated with CheckTOR, a company that’s meant to assist copyright holders (Checktor).

2.2 Glasnost Results
We ran Glasnost from different computers and different ISPs, on different occasions and even through random WiFi hotspots, in order to inspect interference with BitTorrent traffic. Glasnost operates in the following manner: it inspects the connection in four different transfers: BitTorrent upload and download over a standard BitTorrent port and over a non-standard port, and TCP upload and download over a standard BitTorrent port and non-standard port. By comparing the TCP and BitTorrent results, information as to whether deep packet inspection occurs, as it prioritizes traffic according to protocol, and by comparing standard to non-standard port information whether port preference occurs.

We conducted at least 8 inspections per ISP and logged them. We compared the results and analyzed them, and our findings were as follows:

2.2.1 Netvision:
Netvision probably operates both deep packet inspection, which we already mentioned when we found that it may cache popular torrents. Our findings where that in standard port uploads, the average ratio of BitTorrent to TCP was 70%, and on non-standard ports it was 81%; however, aggregated ratios (the aggregate of all the upload speeds and download speeds) were 52% on standard ports and 59% on non-standard ports. In downloads, we encountered similar results, providing an average BT/TCP ratio of 58% on standard ports and 50% on non-standard ports and an aggregate value of 50% on standard ports and 27% non-standard ports.

2.2.2 Bezeq International:
Bezeq International’s results were inconclusive, and because of one inspection, where BitTorrent traffic was 12 times faster than TCP on an upload, the results were inexplicable. Therefore, we omitted this inspection as it was off the standard deviation. Moreover, Bezeqint’s results were inconclusive and could be due to standard deviation in the statistical margin of error, in general, Bezeqint’s BitTorrent traffic was faster than TCP traffic. Our findings where that in standard port uploads, the average ratio of BitTorrent to TCP was 105%, and on non-standard ports it was 69%; aggregated ratios were 104% on standard ports and 52% on non-standard ports. In downloads, however, the average BT/TCP ratio was 147% on standard ports and 130% on non-standard ports. However, the aggregate download ratio had a value of 137% on standard ports and 36% on non-standard ports. This was caused due to several tests where the ratio on non-standard download ports was below 10%. In these cases, we believe that it may be due to momentary errors and not due to intentional interference.

We can only conclude that uploads on non-standard ports had any discrepancies, and therefore believe that no actual throttling was made.

2.2.3 Internet Zahav / Smile012
Internet Zahav’s results were the hardest to obtain. Nevertheless, we found strong indication of traffic shaping. The amount of results omitted due to blocking of BitTorrent ports was material, and was sufficient to show that some P2P traffic throttling occurs. Moreover, the number of results show zero kilobytes as download speed indicate that some shaping or throttling may be practised during certain hours.

Our findings were that in standard port uploads, the average ratio of BitTorrent to TCP was 81%, and on non-standard ports it was 107%; aggregated ratios were 77% on standard ports and 103% on non-standard ports. In downloads, we encountered similar results, providing an average BT/TCP ratio of 74% on standard ports and 118% on non-standard ports and an aggregate value of 90% on standard ports and 80% on non-standard ports.

These results indicate that throttling occurs only on standard ports, and on non-standard ports no throttling is inflicted on traffic. This may be due to either DPI or non-DPI interference.

2.2.4 Table:

ISPBT/TCP upload, StandardBT/TCP upload, non-standardBT/TCP download, standardBT/TCP download, non-standard
Netvision69.99% (52%)81.95% (60%)58.61% (50%)50% (27%)
Bezeqint105% (104%)69.17% (52%)147% (137%)130% (36%)
Zahav81% (77%)107% (103%)74% (90%)118% (80%)

Indication of low BT/TCP ratio shows DPI or throttling of TCP, differences between standard and non-standard ports show potential throttling based on ports.

3. Conclusions
Our findings are that at least 2 of the 3 major ISPs perform manipulation on traffic, and especially peer-to-peer traffic. We were able to show that deep packet inspection and P2P-caching is performed by at least one ISP and that another one probably operates some kind of preference on specific ports.

We believe that P2P-caching is the most troublesome of all activities and that it should be inspected by the regulatory authorities. Moreover, we believe that further research is required to show actual use of restricting technologies and the use of RST packets or other mechanisms. While we could not determine which technologies are being used, we believe that the use of such technologies could be used to block competition, free-speech and allow wiretapping of voice over ip conversations. The use of preferring technologies should be regarded as restriction of access and be stopped.

Source : http://2jk.org

Thursday, December 3, 2009

VMware demo showing two operating systems running on one phone




Last night I search for a way to run Linux on my pocket pc on the windows mobile operating system

So i find these one, I am still working on that for more information just comments below

Monday, November 23, 2009

Google Chrome OS Release Date Expectation



Last night Google Blog posted “Introducing the Google Chrome OS” but no release date was confirmed. Sundar Pichai said Chrome OS is going to be released later this year but our expetation is that Google is going to release it little bit after Windows 7 which is in October.

Google is very known for releasing applications to production week before some other company does. Take a look at the Android 1.5 OS for example, they released it before iPhone OS 3.0 came out. Another good example is Chrome Browser which was released on September of last year but just about 1 month before Chrome was released Firefox 3 came out.

Google tactic is very predictable when it comes to releasing something to production.

First application release they usually do it after some other competitor, because they track users reaction and have 1-2 months of time to either implement “new features” or fix same bugs users complain about it.

By the second release to production they tend to release software before the competitor does.

Wednesday, November 18, 2009

Using SSH Tunnel to connecting the internet


Will the idea is using the SSH
secure channel for browsing the internet how we do that:

First we need to connect to our SSH domain BUT using the -D option with the port 8080

will : ssh root@the-ip -D 8080

and then in the fire fox browser all we need to do is :

Edit >> Preferences >> Advanced >> Network >> Sittings >> Manual proxy configuration >> and change

the SOCKS Host to : 127.0.0.1 and the port to 8080

That is it now you can browsing the internet in a secure mode !!

Friday, September 4, 2009

Linux PC stored in USB key


The French are truly crazy, cramming in the equivalent of a full Linux computer into something as small as a USB key that measures 1.4" x 3.3". Known as the USB-9260, this USB key is powered by an ARM926EJ-S processor at a 190MHz clock speed and is aided by 64MB of SDRAM and a 256MB NAND flash for data storage purposes. Other than the main USB 2.0 port, you also get a couple of USB 2.0 host ports and a 10/100 Ethernet port for additional connectivity options. Talk about a truly compact computer! Don't expect to run any games on this though, as the USB-9260 will probably work great as a portable word processor or number cruncher.


for more information about similar products get in to

שמעות מחלת ה לינוקס הגיעה ל קרן קיימת


נציגנו בשטח שלחו תמונות בלעדיות להתפשטות המחלה



Say Cheese :-)

Friday, August 14, 2009

Installing Ubuntu using windows PXE


ok first we need a Pxe server we will use TFTP server you can download it here
and then we need the netboot for ubuntu and that we can download from here :
or

1.ok install the program that is vary simple
2.and then creak a directory name it PXE on drive C:
3.then run the program and switch to the tab "DHCP Server" and fill in your network setup like that >>

after that click save
4.Now we need to copy the Ubuntu netboot installer over to our PXE root directory
4.1unzip the file netboot
4.2 copy the folder ubuntu-installer to C:\PXE
4.3 copy the folder pxelinux.cfg from ubuntu-installer\i386\ to C:\PXE
4.4 copy the file pxelinux.0 from ubuntu-installer\i386\ to C:\PXE

at the end boot from tftp you may need to activate booting from the network interface in the BIOS

Good Luck





Monday, July 13, 2009

Hacking The library

בוקר טוב לכולם סוף שבוע משעמם אז החלטתי לעשות קצת בלגאן

היום אני צריך מחשב בחינם, איך זה ? השיטה קלה

משאלים מחשב מהספרייה וכול מה שצריך לעשות למחוק את ההיסטוריה של ההשאלה חחח פשוט

טוב צריך את

הסיסמה של אחד מהמפעלים טוב נעשה בדיקה קטנה

זה האתר המסכן של הספרייה שגם עובדי הספרייה משתמשים

אז נפעיל את ה

wireshark

ו בינגו חחחחחחחח זה לא מקודד אפילו

כול מה שנשאר זה לקום קצת מוקדם ללכת לספריה עם כנסת העובדים והשאר תנחשו חחחחחחח

Even Ubuntu 9.04 still not Stable in HP Mini 2133

HP 2133 Mininote

Almost non-usable because of weak VIA Chrome9 videocard support in Ubuntu. Software rendering of UNR interface is painful. Also there are minor problems with non-working mic, unstable falling into suspend and wi-fi not always waking up after resume. Known issues:

  • 358793 - UNR jaunty: Slow interface, high CPU load

  • 365688 - Mic doesn't work in jaunty for VIA VT1708 High Definition Audio

  • 233920 - Sleep on lid close work only 1 time

  • 359291 - Broadcom wi-fi card doesn't work after suspend/hibernate

  • 355918 - resolution problem starting X with the wlan network controler activated

[Dirk-Heine Hofstede] I installed it at my HP mini-note 2133, and except that the UNR interface reacts slow I didn't encounter any problems so far. My wi-fi card just ran normal and made connection again after I woke my mini up(I have done this only once yet). I didn't use the build in microphone yet, so I can't say anything about that.

[Dipock Das] I also installed it on my HP mini-note 2133 and did not have any problems. The WIFI runs fine even after suspend/hibernate.

But after i try it sorry to say it is sucks the high CPU load killing me off

Circular Waveguide Antenna for 2.45 GHz / 802.11b / WiFi / WLAN

Latest version of this document can be found at http://flakey.info/antenna/waveguide/index.xhtml
Last updated - 15th February 2005 | Flakey.info

Overview

We have been experimenting with waveguide antenna, made from old food cans, to massively extend the range of 802.11b wireless networks. All that was required was fitting, in the correct place, a driven element consisting of a short piece of copper wire soldered into the centre of an N-type connector.

Waveguide antenna made from a J&B whiskey can.

One of the antennas made from a J&B whiskey tin.

Note - This antenna is for use with 802.11b or 802.11g wireless computer networks or 2.4GHzvideo sending equipment. It is not for FM / AM / SW / LW radio useage.

This was evolved primarily since the Pringle's can antenna. The Pringle's can, being cardboard, does not last long in a storm, and it is very hard to affix connectors securely. The dipole-less "yagi" bit inside is fiddly to make, and initial tests show the waveguide cans to work better.

From studies of waveguide theory, which gets complicated, it seems that a waveguide antenna or "can-tenna" should have parallel sides, be a good conductor, preferably shiny, and the end needs to be be perpendicular to the sides. For 2.4 GHz the calculations indicate that the can should have a diameter between 70 mm (millimetres) and 100 mm. These are not a "brickwall" limits, but rather roll-off points. i.e. performance will diminish increasingly beyond these sizes.

From practical use we have found that strength is a good virtue, and a fitting plastic lid is almost a must for waterproofing. See appendix for a list of cansfound suitable so far.

The ARRL (Amateur Radio Relay League) say that the required waveguide length is at least two guide wavelengths - The guide wavelength is the value of Lg(in the tables of values below) and is dependent upon the diameter of the can. The smaller the diameter, the longer the guide wavelength. This suggests the larger acceptable diameters should be used so the can may be shorter. Also the larger the area of the mouth of the can, the more energy can be tranferred, so the greater the received and transmitted signal.

Construction

First we selected a can with a diameter of 96 mm. We calculated from this the value for 1/4Lg (a quarter of the standing wavelength inside the can), measured this far up from the bottom of the can and drilled a small pilot hole, then drilled the hole out large enough for a chassis mount N-type connector. It is not easy to find 16 mm drill bits in the UK, so we bought a 20 mm cone cutter. To the pin of the chassis mount N-type connector we soldered about 50mm of 1.5 mm diameter stiff copper wire. This wire was then carefully cut to the value calculated for 1/4Lo. The edges of the N-type connector and the can around the hole were then abraded heavily with glass paper. The N-type connector assembly was then soldered in place to the can, on all four sides. It is important to get a good electrical connection between the N-type connector and the can. Also we have now sourced round N-type connectors which screw into the can (from rswww.com stock no. 112-0773) , and just requires a 16 mm hole drilling.

Inside of the can showing driven element

Inside of the can, showing the driven element. Photo not taken whilst in use.

The cone cutter will cut a perfect hole if the 16 mm washer from the connector is placed over the tip before cutting. With the tools to hand, the whole process took ten minutes.

After a couple of years of experience and learning using these cantennas, it appears that it makes sense to drill a small hole in the can just behind the N-type connector. Thus any rain or condensation which finds its way into the can has an easy route out. The hole should not affect the performance of the antenna.

Detail showing N-type connector affixed to can.

Detail, showing N-type connector affixed to the can.

Mounting

This antenna has a beamwidth of around 30 degrees and needs aiming. Also the polarisation is important, that is whether the driven element inside is pointing skywards (vertical) or sideways (horizontal) - this needs to match the antenna it is communicating with. We have been mounting them around a standard 25 mm television pole with a U-bolt attached to an adjustable mounting from a television antenna shop - this allows adjustment in the horizontal and vertical plane. This has then had a short piece of stainless steel tubing clamped in, attached to the can with glue and gaffer tape, or cable ties. None of these are a very good solution. This is one point needing more thought...

A can-tenna mounted on a television antenna pole.

A can-tenna mounted on an existing television antenna pole.

It was nescessary to aim the antenna before tightening the bolts fully, and check the polarisation was correct. This involved having the N-type cable attached to a PCMCIA (Personal Computer Memory Card International Association) card in a PC (Personal Computer) or laptop with someone down below monitoring the signal, although I have taken a laptop up on the roof - it is not adviseable. An ideal solution would be a hendheld PC with 802.11b card, and pigtail....

Note - always point a can-tenna away from you, and do not look down into the can whilst running. This recommendation is based on caution rather than known danger. Human eyes have very little cooling, and hence are the parts of the body most likely to absorb, and fail to dissipate, excess microwave energy. The can is a focussed microwave device, thus better safe than sorry.

The can-tenna connected to an N-type cable

The can connected to an N-type cable.

We maximised the signal by aiming the can-tenna roughly by landmarks, and the use of a compass, and then moved it bit by bit sideways and then up and down until the maximum signal to noise, or link quality was achieved. This required the use of a wireless tool for the PC. I used Wavemon for GNU/Linux, but most wireless card drivers have some form of link quality read-out. Depending on where the monitoring PC was, we needed extra people, or walkie talkies, mobile phone etc. to relay the signal strength after each adjustment. Once the maximum signal was achieved, we clamped up the bolts tight, and celebrated a job well done.

Cost

£5.50 for the N-type connector, and the can of your choice, plus the little bit of wire, and a tiny bit of solder. When we spent £20 on our can we got a free bottle of whiskey. ;-)

Warning

Apart from the fact it works really well, no-one has yet popped on their lab-coat and done any high-brow tests on this "homebrew twig", and of course manufacturers recommend you don't do anything which they don't recommend. Or attach non-proprietary stuff to their stuff. Of course.

Tests on first construction

Our first waveguide antenna had a diameter of 96 mm, with a length greater than 3/4Lg and was made from a can which came with a bottle of gin :-)

The antenna was fitted with a standard television 75 Ohm connector (not a proper N connector). The pigtail used was made by removing the lead from a Buffalo Extended Range Antenna and attaching a standard television 75 Ohm connector. We are aware that the combination of 50 Ohm coaxial cable and 75 Ohm connectors is not a good impedance match and would result in loss, but at the time of testing, in Portugal, that is all we had, and we were keen.

Comparison was made with respect to the internal antenna on a Buffalo PCMCIA 802.11b card. Using Wavemon (a wireless measurements tool) on aGNU/Linux laptop to measure received signal strength, noise and signal to noise ratio.

Results

Our first can, including cable loss we received around +4 to +5 dB (deciBels) improvement in received signal strength, and a +10 dB improvement in signal/noise ratio.

Looking at data tables we estimate the coaxial cable used to have a 1.5dB loss.

This antenna allowed us to maintain an 11 Mbps connection at 200 metres from the Buffalo Airstation Extended Range Antenna. We could not walk far enough with clear line of sight. We were impressed that this improvement was measured even using cheap television connectors from the supermarket (at the wrong impedance).

First mountain test

Finally we managed to get hold of some 50 Ohm N-type connectors. Unfortunately no-one seemed to stock the mating pair so we had no option than to reduce to BNC and back up again at the other end. This worried us not as we were eager.

The only cable we could get hold of was RG58/U, fairly high loss

We attached a gin can waveguide antenna to the Buffalo airstation, via 10 metres of cable, and pointed the antenna out of the window towards the HILL

Iain went to the top of the HILL with his laptop, running Wavemon on GNU/Linux, and a dogfood can-tenna, via 2 metres of cable. The top of the hill has two large multi-sector mobile phone antennas, broadcasting around 800MHz, we believe. Iain was positioned roughly 50 metres below them (slowly frying his brain!).

We had a clearish (tree tops) line of sight down the valley which measured 2200 metres point to point on the military map.

Results

We achieved a 2Mbps connection, with around 7 to 8 dB to spare, although in the excitement the figures got a little lost. Well, completely lost. The important part for us at this point was that it worked.

Having looked at the specification sheet for the cable we were using, it seems not to rate as high as 2.4GHz in the losses, the highest rating is at 1000 MHzwhich is 0.79dB per metre. This means that by using far too much of the wrong cable we have cost ourselves 9 to 10 dB. This is good news for our next hilltop shot with short good cables, and suggests a clear 5000 metre shot.

The can shown above has given us 16 to 17dB improvement over the antenna on the Buffalo wireless card. This is successful. We are very happy with the results of this can.

We are now awaiting some spare time and enough clear space to do further range tests. We are expecting 10,000 metres on a can to can link.


Appendix

List of tins so far found to be suitable

  • Slimfast Double Chocolate - England - with plastic lid
  • The Simpsons Double choc cookies - England - with plastic lid
  • Douwe Egberts ground coffee - England - with plastic lid
  • Baby milk formula - England - with plastic lid
  • Furness Ginger Biscuits - Cornwall and England
  • Golden Jubilee Beer, Robert Cain Brewery - England
  • Nestlé Coffee Mate 500g - England - with plastic lid (thanks to Mark Gaved)
  • J&B Rare whiskey tin - Portugal
  • Larios Gin - Spain
  • Stainless steel toilet brush holder from B&Q - very nice (thanks to Robert Currey)
  • Any large dog food tin at a push, if you can't find anything better!

Some colourant additives in the plastic lids affect signal, so test with lid off and on, and if the signal is detrimented, use without.

References and links

Circular waveguide antenna calculator - JavaScript

See Fig1.1 for how to use values - most of them are unnescessary and slightly confusing.

  • D is the interior diameter of the can
  • Lo is wavelength in open air = 0.122 metres
  • Lc is wavelength at lower dominant mode cut off frequency
  • Lu is wavelength at higher dominant mode cut off frequency
  • Lg is standing wavelength inside can

Lc = 1.706D

Lu = 1.306D

Lg = 1 / (sqr_rt{(1/Lo)2 - (1/Lc)2})

Ideally for the usual operating range of 802.11b:

  • Lower cut-off frequency should be lower than 2400 MHz
  • Upper cut-off should be higher than 2480 MHz

D in mm

Lower cutoff frequency in MHz

Upper cutoff frequency in MHz

Lg in mm

Lg / 4 in mm - needed to make can

3Lg / 4 in mm

Lo / 4 in mm - needed to make can

Circular waveguide antenna.
Fig 1.1 - Circular waveguide antenna showing design values, click to enlarge.

Table 1.1 - wavelengths and frequencies against diameter

See Fig1.1 for how to use values

D in mmD in
inches
Lower cut off
frequency in MHz
Upper cut off
frequency in MHz
Lg1/4 Lg3/4 Lg1/4 Lo
732.8742407.2363144.522752.281188.07564.21130.716
742.9132374.7063102.028534.688133.672401.01630.716
752.9522343.0433060.668440.231110.057330.17330.716
762.9922312.2143020.396384.70896.177288.53130.716
773.0312282.1852981.17347.27686.819260.45730.716
783.072252.9262942.95319.95879.989239.96830.716
793.112224.4082905.697298.95574.738224.21630.716
803.1492196.6032869.376282.20470.551211.65330.716
813.1882169.4852833.952268.47167.117201.35330.716
823.2282143.0272799.391256.97264.243192.72930.716
833.2672117.2082765.664247.17861.794185.38330.716
843.3072092.0032732.739238.71959.679179.03930.716
853.3462067.3912700.589231.32957.832173.49730.716
863.3852043.3522669.187224.8156.202168.60730.716
873.4252019.8652638.507219.0154.752164.25830.716
883.4641996.9122608.524213.81353.453160.3630.716
893.5031974.4752579.214209.12652.281156.84530.716
903.5431952.5362550.556204.87651.219153.65730.716
913.5821931.082522.528201.00250.25150.75130.716
923.6221910.092495.11197.45649.364148.09230.716
933.6611889.5512468.28194.19648.549145.64730.716
943.71869.4492442.022191.18847.797143.39130.716
953.741849.7712416.317188.40547.101141.30430.716
963.7791830.5022391.147185.82146.455139.36530.716
973.8181811.6312366.496183.41545.853137.56130.716
983.8581793.1452342.348181.16945.292135.87730.716
993.8971775.0332318.688179.06844.767134.30130.716