This article started as an investigation of astrological cycles relating to the birth horoscope of the United States in an effort to develop “historical proofs” for the Tibetan (Djwhal Khul, D.K.) Master of the Wisdom’s statement that the USA has a Gemini Sun with Aquarius Rising (Destiny of the Nations by Alice Bailey, pg. 51-52 & 82-83). It evolved into an historical analysis proving the efficacy of Astrology and the the role played by Uranus and Pluto in the psychology of the USA and world events, with implications for the upcoming period between now (Mar. 24, 2022) and 2036. Astrologers conventionally cast the United States Natal chart using the July 4, 1776 signing of the Declaration of Independence for the birth date. But this date produces a Natal Sun in the sign Cancer and is in conflict with D.K.’s statement of a Gemini sun, implying that July 4th is not the correct “Birth Date”. However, those with an historical understanding of the period do find other, better and more esoterically valid dates. Personally, this author finds the period of June 2-7, 1776 to be quite interesting. Let us look at history and cycles to see if we cannot substantiate DK’s […]
This article has absolutely nothing to do with iPhemeris software and is simply a side interest. The attached paper is a little thought experiment undertaken to test the Military Abduction (MILAB) assertion, which states that all people reporting having been abducted by aliens are actually being abducted by some government entity as part of some disinformation campaign purportedly to hide the fact that we have some kind of top secret technology. The people making this assertion refer to these as Military Abductions or MILAB. The reasons given for why any government would use the very technology it is trying to hide to conduct highly illegal operations and which are far more likely to have exactly the opposite effect and expose said technology, are never very clear. Personally, this writer has always found the MILAB assertion to be rather illogical not to mention insulting and disrespectful to the thousands of people worldwide who are reporting these extremely traumatic events. I believe the abductees and what they say and know several personally. Also, whilst I am not being abducted, I have encountered aliens personally and directly on two occasions and for me, their existence is not theoretical, it is a personally verified […]
iPhemeris has now been extended to cover a date range of 7700 years from 4700 AD to 2995 BC and also has gotten dramatically smaller in size on disk. We accomplished this by adopting the Swiss Ephemeris which has excellent data compression and which also makes it fairly easy to add additional asteroids and hypothetical bodies with minimal impact to the size of the App. iPhemeris formerly used our own version of the JPL Ephemeris (DE 431) but this was very large and additional asteroids only made it more so. We therefore considered that as the Swiss Ephemeris had the same underlying JPL DE 431 data quality but much, much better data compression we might as well switch. We decided we preferred to add features than to spend time working on data compression. By simply adopting Swiss Ephemeris we can now offer many more astronomical bodies and hypotheticals but with a substantial reduction in App sizes on device. This will have major benefits for the iOS versions of the App. Thank you Astrodienst for your work!
Geek alert! This is a technical article about some of the issues I ran into whilst extending iPhemeris’s Ephemeris to cover a 5000 year period from 2500 BC to 2500 AD. Initially I’d thought it would be a simple matter to add a few thousand more years to the database. Devices have a lot more storage these days and network and download speeds are faster than when iPhemeris was first created. So why not, easy peasy right?! I did the work to read the JPL Ephemeris files and the USNO asteroid ephemeris over 8 years ago (both use the same format to store data) and could easily create what iPhemeris uses in any format. So creating a database that covered a longer period of time was really only a matter of a few days work and given the relative frequency of requests for more data, I thought why not just add it as an In-App purchase. It took only a few hours work to create the new tables and pull in 4 more asteroids/planetoids from the USNO Ephemeris (the more frequently requested ones): Hygiea, Astraea, Eris and Sedna. Then set about updating the various places in the iOS and MacOS versions of the code that […]
Announcing Version 3.0 (Mac OSX) of iPhemeris extends the Ephemeris to 5000 Years (2500 BC to 2500 AD). The ephemeris expansion also adds 4 important planetoids/asteroids: Astraea, Hygiea, Eris and Sedna. The expanded coverage works with all features including: Astrological Charts Tabular Ephemerides Graphical Ephemeris Astrological Calendars It is now possible to do anything the program is capable of for any date or date range between 2500 BC and 2500 AD. In addition to the extended ephemeris, we made many other small improvements and fixed numerous minor issues making this version of iPhemeris the best yet and something you will want to update to as soon as possible.
Happy Holidays and welcome to Mercury Retrograde! If you are seeing charts that look something like the image below there is a simple fix, but first a brief explanation. The problem began with iPhemeris v10.4.0 for iOS. It happens intermittently and ONLY on devices running iOS 10.x Today (Dec. 24), I learned it is caused by a fairly major iOS 10.x bug (Apple’s bug, not mine) The bug affects the way preferences are saved and manifests most obviously in relation to orb preferences for the 4 new aspects 10.4 adds: Decile (36°), Septile (51.4°), TreDecile (108°) and QuinDecile (165°). When iPhemeris first launches it attempts to update Orb Preferences and add default orbs for the new aspects if they don’t already exist. However, because of the iOS bug this randomly fails and with hundreds of thousands of devices using iPhemeris that is unfortunately fairly often. After getting reports of it (some quite nasty actually) and a few pictures I guessed what might be going on and attempted a fix in 10.4.1. However because of the iOS bug this didn’t work. Not knowing about the bug at the time, I attempted a second fix with 10.4.2 and which also included a way to get some diagnostic information. The diagnostic data confirmed that what I though […]
Updates for both iOS (v10.3) and macOS (v2.4) were just released!! This was primarily a maintenance release but it did have some minor improvements and enhancements. Primarily these were: Graphic Ephemeris – Got its own color preference setting. Midpoints can be sorted by either Planet or Sign. This iOS version resolved a Graphic Ephemeris display issue when using a degree range smaller than 45°. This is the same fix that was included in a previous release of the macOS version. More good things are coming soon! Onward and Upward, iPhemeris
iPhemeris for iOS and Mac updated today and include a major new feature: the Graphic Ephemeris. This update includes: NEW: Graphic Ephemeris Display Longitude and Declination. Display harmonic degree ranges. Good for finding weird aspects like 45 degrees. Overlay chart data. Added: Composite +Now. When 2 charts are selected an option to display a Composite and a now chart has been added. Added: 7 day time step. Charts can now be time-stepped in 7 day increments. Fixed: Vertex and Descendant display issues on Transit Calendar. Fixed: “Slow typing” issue for chart date entry (Mac version). This only happened on the Mac version and was related to a minimum date condition set on the date entry fields. The mac has some built in timer and if users entered dates too slowly it would decide the minimum date (Jan 1, 1700) was not met and replace what was being typed with Jan. 1 1700. I couldn’t control the timer and had to simply remove the condition. Check out it out: