I have been trying to get a number of Wifi Service Providers to set-up in the local area, but so far none have been able to provide connectivity for my local area. Companies I know of, which provide Wifi connections in the North Wexford area where I live include:
I’m still talking with Alpha Broadband with a view to setting up an access point at the local Ballywater wind farm near where I live. Hopefully something will come of this.
Anyway, it turns out that Eircom, which is the main telecom company here in Ireland have been doing upgrade work over the last few months, to the phone lines between my house and the local exchange which is 5.1 KM away as the phone lines run. Last year, I got my phone line testing for broadband and it failed. I assumed it was the distance which was causing the failure (as DSL starts to run out of steam at around the 5KM mark) and left it at that. But just recently a next door neighbor was able to get DSL following an engineers site visit. It turns out that a lot of phone lines which were installed a long time ago in the local area were so called "Multichannel Carrier Lines". These are where a single line from the exchange is split into 4 separate lines on a telephone pole close to your house. These 4 lines then serve separate households. These type of lines are completely unsuitable for broadband and even affect the rates you get when on ordinary dial-up to the Internet. One neighbor I know is lucky if he gets 33.6K when he connects via dial-up!.
If you can get a new standard ordinary cable installation phone line or get your existing line converted to this, then even at over 5 KM from the local exchange you stand a good chance of getting DSL. Just last night I was helping out a neighbor with their broadband connection and they would be just 400 meters or so closer to the exchange than myself. I was surprised to see that the DSL router was reporting that it was connecting at 2MB downstream.
After dealing with Eircom support before Christmas, they advised that I get a new standard phone line and hopefully I should then be able to get broadband on it. At a later date, I could then transfer my existing phone number to the new line and decommission the existing one. An Eircom engineer duly arrived last week and installed the new line. I had a good chat with the engineer and he was able to give me a lot of good information on how the physical phone line systems are constructed. Once the line was commissioned by the engineer, I went back to the Eircom web site and checked the line for comparability with broadband. Initially it said it was unable to determine the capability and the engineer said it was best to give it a day or two before you try to apply again. Later in the week, I tested the line again and this time it failed. Now I had two phone lines and neither were compatible with broadband. To say I was feeling let down was an understatement of the month.
After giving out about about the state of broadband in the local Strand Bar pub one night to some fellow pub-quizzers, one person suggested that I talk to one of my neighbors who happened to be a senior engineer with Eircom. I do not know what magic or pixie dust he used, but just today, the online test says that my phone line is now suitable for broadband subject to confirmation. The highest spec package it said my line was suitable for was 2 MB downstream and 256K upstream, which I’ll take any day of the week.
Hopefully I should be getting my self-install pack from Eircom in the next few days which includes a standard Netopia 3300 DSL Wireless Router. I will keep you informed of my luck with finally getting properly on the Information Superhighway.
- Updated copyright details.
- UsingSetupAPI code now uses the GUID_DEVINTERFACE_COMPORT guid to
enumerate COM ports. Thanks to David McMinn for reporting this nice
- Detection code which uses CreateFile call, now treats the error code of
ERROR_SEM_TIMEOUT as indication that a port is present.
- The static version of the CAADate::Set method has been renamed to DateToJD to avoid any confusion with the other Set methods. Thanks to Ing. Taras Kapuszczak for reporting this issue.
- The method CAADate::InGregorianCalendar has now also been renamed to the more appropriate CAADate::AfterPapalReform.
- Reinstated the bGregorianCalendar parameter for the CAADate constructors and Set methods.
- Changed the parameter layout for the static version of CAADate::DaysInMonth
- Addition of a CAADate::InGregorianCalendar method.
- Addition of a CAADate::SetInGregorianCalendar method.
- Reworked implementation of GregorianToJulian method.
- Reworked implementation of JulianToGregorian method.
- Updated copyright details.
- Class now by default sports a tooltip with the hyperlink text as its
- Class now only shows the underline when the hyperlink is highlighted.
- The "EnableLink" property has now been removed. Instead you can use the
standard windows WS_DISABLED style. By also doing this, the code now no
longer requires the disabled cursor resource.
- Class now reverts to standard static control colors and style when
- Removed code which loads up the IDC_HLINKCTRL_ENABLED_CURSOR cursor.
This now means that the code has no dependency on any resources which you
need to add to your project.
- After a bug report from Ing. Taras Kapuszczak that a round trip of the date 25 January 100 as specified in the Gregorian calendar to the Julian day number and then back again produces the incorrect date 26 January 100, I’ve spent some time looking into the 2 key Meeus Julian Day algorithms. It seems that the algorithms which converts from a Calendar date to JD works ok for propalactive dates, but the reverse algorithm which converts from a JD to a Calendar date does not. Since I made the change in behaviour to support propalactive Gregorian dates to address issues with the Moslem calendar (and since then I have discovered further unresolved bugs in the Moslem calendar algorithms and advised people to check out my DTime+ library instead), I am now reverting these changes so that the date algorithms are now as presented in Meeus’s book. This means that dates after 15 October 1582 are assumed to be in the Gregorian calendar and dates before are assumed to be in the Julian calendar. This change also means that some of the CAADate class methods no longer require the now defunct "bool" parameter to specify which calendar the date represents. As part of the testing for this release verification code has been added to AATest.cpp to test all the dates from JD 0 (i.e. 1 January -4712) to a date long in the future. Hopefully with this verification code, we should have no more reported issues with the class CAADate. Again if you would prefer a much more robust and comprehensive Date time class framework, don’t forget to check out the authors DTime+ library.
- Optimized CAADate constructor code
- Provided a static version of CAADate::DaysInMonth() method
- Discovered an issue in CAADate::JulianToGregorian. It seems the algorithm presented in the book to do conversion from the Julian to Gregorian calendar fails for Julian dates before the Gregorian calendar reform in 1582. I have sent an email to Jean Meeus to find out if this is a bug in my code or a deficiency in the algorithm presented. Currently the code will assert in this function if it is called for a date before the Gregorian reform.
- Changed name of CAAMoonIlluminatedFraction::IluminatedFraction to CAAMoonIlluminatedFraction::IlluminatedFraction. Thanks to Ing. Taras Kapuszczak for reporting this typo!.
- Updated the documentation to use the same style as the web site.
- Code now uses newer C++ style casts instead of C style casts.
- Optimized CMainFrame constructor code.
- Now uses v1.11 of the authors CAVICapWnd class
- Code is now built and delivered using VC 2005 SP1.
- Now uses v1.09 of the authors CFTPTransferDlg/CFTPTransferer classes.
- Now uses Themes when run on Windows XP.
- Prebuilt binary included in distribution is now compiled for Unicode.
- Addition of a new "FTPUI" configuration value.
- Code now no longer bothers requesting that the device set its video
format to 24 BIT RGB.
- Default TimerInterval is now set to 2000 in the ini file included in the
- Main VFWGrab window is resized just to fit the specified client area on
start-up. Thanks to Jason Pettiss for suggesting this update.
- Now includes comprehensive support for date and time replaceable
parameters in the "RemoteFile" and "File" parameters. This functionality is
provided by the author’s
DTime+ class library. Thanks to Jason Pettiss for suggesting this
update.If the application is minimized when it is about to take a capture, the
window will now restore itself (without stealing the focus). This ensures
that an up to date image is captured. Thanks to Jason Pettiss for
suggesting this update.
- Fixed a minor compliance issue with GCC in the AACoordinateTransformation.h to do with the declaration of various methods. Thanks to Mathieu Peyréga for reporting this issue.