The light curves of the two recent bright southern novae, V462 Lup and V572 Vel, have developed somewhat since I last wrote about them, the first peaking at magnitude 5.2, now 11.1, and the second peaking at 4.8, now 10.3.
T CrB remains quiet and foreboding, low in the early NW evening sky, taunting us with its pre-eruption ellipsoidal variations.
Writing this update reminded me of a long-standing plan to write a nova distance calculator plug-in for VStar, based upon the rate of decline of a nova.
A 2020 ABC News article about a semi-trailer carrying chickens in Adelaide (of exactly the sort I recently wrote about in Estimated Witness) contains the following mind-bogglingly insane words:
The RSPCA attended the crash scene.
Spokeswoman Carolyn Jones said the chickens involved in the crash were taken to an Ingham’s processing facility at Burton in Adelaide’s north where their welfare would be assessed.
Up to 1,000 chickens died.
“Clearly a very distressing scene with so many crates that had toppled over and many birds that were loose,” Ms Jones said.
“We’ll be monitoring the welfare of the surviving and the injured birds.”
Umm. Their welfare would be assessed… At an Ingham processing facility…
It makes me feel so much better to know that the RSPCA was on the scene, and that Ingham and RSPCA were keeping an eye out for an unknown number of chickens’ welfare…
RSPCA Approved chicken. It’s in the name, along with their oxymoronically titled podcast: Human Food.
Up to 1000 chickens died. On the scene or in the “processing facility”? Ultimately I’d say 100% died except those who managed to run the hell away from the truck and didn’t get run over by a car.
Seriously!!
They were on their way to be slaughtered!
The only thing a chicken slaughterhouse “cares about” is whether or not it’s worth “processing” (euphemism alert!) a chicken or disposing of its dead or dying body! It’s all about the cost!
And who knows what the RSPCA cares about. Cute cats and dogs and bugger all else apparently. Kick a dog and we’ll prosecute you. But slaughter as many pigs, cows, sheep and chickens as you like. That’s fine. They’ll even approve the death of pigs and chickens so long as they “lived well” and were slaughtered “humanely”. Oh, and don’t export live sheep! Just kill them in Australia!
In December 2001 I soldered 25 red LEDs and 5 resistors onto a square of veroboard:
LED grid with PIC at right and Arduino at left (connected)PIC 16F84 microcontroller (source: Microchip)ATMEL ATMega 328PU microcontroller on Arduino dev board (source: Microchip)
then connected a locally produced PIC16F84 microcontroller development board via ribbon cable soldered to the veroboard, and a home-made power supply to it, wrote C code to create frames of patterns that changed over time, and used it as a Christmas decoration. It has been up each Christmas and New Year for the past 24 years at Christmas and New Year. The video below shows some of the patterns it has displayed.
Each time the code (or even just patterns) changed, the PIC microcontroller had to be removed from the development board, inserted into a programming board, and the binary (.hex format) including code and static data (e.g. pattern frames) uploaded to the device via a serial connection to the programmer board, then placed back into the development board .
I’ve used quite a few programmers over the years, starting with a parallel port programmer I built from a kit in conjunction with free software to write, read and verify bits written to the microcontroller. After parallel ports went the way of the dinosaur, and before USB ports were common, serial port pins were used to “bit bang” data to the microcontroller via a PIC pin, one bit at a time. Over time, serial ports became extinct too, and a USB to serial cable did not work as a replacement because the wires over which to bit bang data were absent. So, I kept an old Windows 95 laptop around for this purpose, since it still had serial port.
Compiled files (.hex files) had to be transferred to the laptop via a USB memory stick from one of a number of computers I used to write and compile the code on (Windows, Mac). Over time the C compiler had to change as well, from Hi-Tech to MPLAB.
I figured that one day the Windows 95 laptop was going to stop working or I would lose the only USB stick that worked with it.
So, in December last year (2024) I finally decided to change the microcontroller from a PIC 16F64 to an AVR based Arduino which has a cross-platform development environment and allows code to be read/written via a USB cable. That’s been the case for a decade or more now for many microcontroller and similar devices.
Although the General Purpose Input/Output (GPIO) pins changed, just 3 lines of the original C code had to be changed to get it to work with the Arduino! That’s is a testament to C. Had it been written in PIC assembly code (and I’ve written my share of machine-level code) or some now extinct special purpose language, or a compiler that’s no longer available or supported (or only on one operating system), a total rewrite would have been necessary.
To me, microcontrollers are like what microcomputers were 40 to 50 years ago, but with no operating system, except perhaps a bit of code that loads other code into a device. Early microcomputers (e.g. Apple I or II, TRS-80, Commodore Vic-20/64) didn’t have much of an operating system either. They just booted up into a read-eval-print loop (REPL) and called other code to load programs from tape or disk, display characters on the screen, play sounds and so on, often supported by specialised hardware.
The Arduino platform provides common pinouts irrespective of processor (e.g. AVR, ARM), a platform independent Integrated Development Environment (IDE), C++ as the development language, a common Application Programming Interface (API), a library of common code for many peripheral devices (e.g. keypads, LCDs), and a USB to serial programming and I/O route.
Before the Arduino, it was the wild west, like it was before the PC and Mac came to dominate. That diversity was interesting however, and 20 years ago I tried my hand at writing generic library code that was likely to work with multiple microcontrollers, and experimented with writing compilers (and interpreters) for various languages to run on microcontrollers. Starting from scratch is not necessary now.
The PIC16F84 had less than 100 bytes of RAM and less than 2K of non-volatile program (FLASH storage) and could run at between 4 and 10 MHz. I later replaced the PIC16F84 with the PIC16F628 which had more than 200 bytes of RAM, 3.5K of FLASH and had a clock speed of 20 MHz.
Optimising the code and patterns that were stored mattered a lot on these small devices!
Compare this with the AVR ATMega 328P used on the Arduino I switched to. It has 32K of program FLASH and 2K of RAM, although the clock speed is only 16 to 20 MHz. Still small by the standards of many microcontrollers now and orders of magnitude smaller when compared to the resources available on even the most modest laptop or smartphone today.
The AVR was made by ATMEL, which was eventually acquired by Microchip, maker of PIC microcontrollers, ironic because of the fierce rivalry between the two companies at one point, amusingly exemplified by this sticker:
The processor, clock speed, memory and on board peripherals in microcontrollers have improved significantly over time, and devices like the RPi PICO have more powerful processors (typically ARM based) and can be programmed either as an Arduino device or can run MicroPython, making it much easier to create more complex gadgets. But that’s for another post.
There’s a lot that can be explored in the world of microcontrollers, which are distinct from other small devices such as Raspberry Pi, NVIDIA Jetson, Beagle in at least one important way. The latter are full fledged computers that run an operating system, typically a variant of Linux.
Unless a microcontroller is running an interpreter, the code you write takes over the device completely. There may be a small boot-loader that loads the program to be run, but nothing like an operating system. Ultimately, when you program a microcontroller, the only code running is yours, compiled or assembled from a human-readable language into machine code. You control the vertical and the horizontal. If the device does nothing or if it does the wrong thing, it’s because there’s an error in your code or you wired something up incorrectly. Either way, it’s on you.
When I started writing for the PIC, it really wasentirely my code, nothing I had not written myself vs use of Arduino library code. In the case of this simple LED grid, it still is all my code. Either way, this complete control over a device is appealing in an age of bloated operating systems, an enormous emphasis upon cybersecurity, and wasted power.
Microcontrollers are also an example of so-called green computing. There is an emphasis on low power consumption and small footprint.
That’s a topic worth exploring more in an age of Blockchain and more recently, Large Language Models. For example, some machine learning models can be trained on a more powerful computer, then run on a less power hungry microcontroller.
Another topic worth exploring is zero-instruction set computing.
A couple of months ago I was asked to give an update at the July 2 2025 ASSA general meeting about T CrB, the binary star system that is anticipated to reach magnitude 2 or 3 when it goes into outburst as a recurrent nova (one of only 10 known), which it has done a few times before at roughly 80 year intervals.
In the meantime, we had two bright southern hemisphere novae (around magnitude 5) in June, so my T CrB talk turned into an update about 3 novae: T CrB, V462 Lup, and V572 Vel. The second and third were the subject of my last two posts.
My update was followed by a great talk about variable star photometry with the Seestar S50 by a former colleague, Andrew Murphy. The slides for his talk (and a course project) are here, as of 20 July 2025.
Here’s the PDF for the talk I gave, with thanks to Kym Thalassoudis for allowing me to include his images of V462 Lup and V572 Vel:
We may still be waiting for T CrB, but within less than a month we’ve seen 2 bright southern hemisphere novae: V462 Lup and now PNV J10251200-5331109 (aka V572 Vel)!
Technically it’s still classed as a possible nova (PNV) before spectroscopic confirmation, although there was a positive Gamma-ray Space Telescope observation overnight while I was sleeping.
Australian John Seach (NSW) discovered this (at magnitude 5.7), and Andrew Pearce (WA) independently found it (magnitude 5.5) on June 25 .
This object has eta Carina at its upper left in this Stellarium screenshot, and below it the “false cross” which consists of stars from Carina and Vela.
This smaller field of view provides more detail with 3 stars at the upper left of the false cross asterism (if the cross was standing upright) at bottom of the picture.
The observing campaign for PNV J10251200-5331109 (aka V0572 Vel) reports the progenitor star as likely being a 22.2 blue star with large amplitude variability.
The sky conditions were not great last night, but I estimated the nova candidate at 4.8 through 15×70 binoculars, through gaps in cloud with DSLR photometry pending.
Rotate this 20 degree FOV AAVSO finder chart 90 degrees right to get the false cross asterism in the same orientation as the screenshots above.
This 8 degree FOV finder chart provides the comparison stars of interest at the moment within a binocular field or two.
As I write this there have been less than 40 observations submitted to the AAVSO International Database.
After being away for a couple of days, I read an email yesterday from Andrew Wendelborn (ASSA) before seeing the official announcements, so thanks for the early heads-up Andrew! The timing worked out well in general.
A nova, now designated V462 Lup, was discovered on June 12 by the ASAS-SN survey at magnitude 8.7 and has since risen to around magnitude 5.5. It has apparently not yet peaked. The progenitor star is thought to have been around magnitude 22, and as with all novae, the rapid brightness increase over a few days is impressive (although not as rapid as some).
Lupus, and the nova, are high in the evening sky as shown in this Stellarium screenshot:
The orientation here is at around midnight on June 21 2025 but Lupus is visible from early evening. This Stellarium screenshot shows the region around the nova corresponding to the image at top.
With the help of this AAVSO finder chart I have made a few visual estimates and there is some DSLR photometry pending. The visual light curve as of the early hours of June 21 is shown below with two of my binocular visual estimates in purple, the last one just a few hours ago:
I’ve been observing the constellation Corona Borealis (CrB) as often as possible since late February at around 5 or 6am. Daylight Saving Time ended here just over a week ago. With CrB gradually becoming observable earlier, if I’m still awake at 1am (fairly often), I can observe it (with binoculars) before I go to bed now.
By going more carefully into the dates of occurrence of the past eruptions, one finds that the successive events date separations are an integer multiple of the orbital revolution period.
…
In summary, the eruptions are not strictly periodic, but the eruptions were all separated by an integer multiple of the orbital period 227.5687 days.
From that, I tentatively infer that the eruption date after 1946 February 9 should be 2431861 + N*227.5687 where N is an integer close to 128, if the orbital period remains constant.
The upshot was predictions for the T CrB eruption of March 27 2025, Nov 10 2025 or June 25 2026. The popular press latched onto this article and suggested a greater certainty than was warranted. It’s now a few weeks after the first of these dates and no nova eruption has occurred yet.
We will see about November. In the meantime, we wait.
I started observing the constellation of Corona Borealis (CrB) again this week, in preparation for the recurrent nova T CrB (aka The Blaze Star) to erupt. This was the first time I’ve done so since early October 2024, when the constellation left Adelaide’s evening sky.
On February 20th from around 5:15am, I spent 45 minutes or so reacquainting myself with the region through hand-held 7×50 binoculars, reminding myself of the comparison stars I’ll use to estimate the change in brightness of the nova, and the asterisms that will help me remember where they are.
Even pre-eruption, T CrB is observable in a small telescope at around magnitude 10, but from suburban skies, anything fainter than magnitude 6.5 or 7 is difficult through 7×50 binoculars, especially when twilight approaches. Still, it’s perfectly good enough to be able to say whether the nova event has happened.
As a reminder, the nova was anticipated before the end of 2024, but nature doesn’t always cooperate with our expectations. When the eruption does happen, T CrB will be visible without the aid of binoculars or telescopes, as bright as alpha CrB aka Alphecca (see the image below).
Why start observing it again now? For two reasons.
That part of the sky is observable from here again, even if at 5am.
There is recent evidence from spectroscopic observations that the rate of accretion of material around the white dwarf from the “donor” star in the pair that makes up T CrB (or any nova system) is significantly increasing. Such an increase, if it’s happening, may be a sign that the thermonuclear runaway is close.
Given Murphy’s Law, it will be entirely possible to miss the initial brightening, since observing 2 or 3 times a night (as I was doing last year for awhile) is not so easy in the wee hours, given the need to sleep and work, not to mention that some nights/mornings will be cloudy!
Still, it won’t stop me, and many others, from trying and in any case, the nova will be easily observable for several days either to the naked eye or with binoculars.
Here’s hoping we’ll have a bright nova (the brightest of all known recurrent novae) sometime in 2025!
