Not definitely yet.

I have added auto wlan0 to /etc/interfaces. That now let’s me see my networks.

It still doesn’t connect automatically to the internal WiFi, though.

I have not gone through this possible solution yet:

weworkweplay.com/play/automatically-conn...i-to-a-wifi-network/

If you try it out, please let us know if it works.

Cheers

Jo

Read More...

Robomort wrote: Explaining computers did a quick test last week. www.youtube.com/watch?v=VJC6OpGpq0Y .
I would say however the second device where the heatsinks sandwich the board is a bit of a designers wet dream since the lower half is the most expansive but is not really thermally connected to the board only at the screw lugs to the top.
I prefer the Kodi branded unit since it performed better and totally enclosed the board.
Neither of course are suitable for a two layer stack but give insight into what works best. Use that knowledge to find other similar but taller solutions which no doubt will be available now or in the near future.
Personally I am using the Rock Pi 4 running a DIY Stellarmate install. They have a solution to house their board and an second layer and SSD. Rock Pi 4 sensibly placed the SOC on the bottom of their board making heatsinking much easier.

ppapadeas wrote:

El Corazon wrote: I would suggest including a ground and a +5V pin on the BOTTOM of the board, to allow for the direct connection of the tower cooling fan (without having to run the wires around the HAT board and connect them to the pins on top).

Noted! I am all for leaving extra ports for things that might be useful in the future Although I think that the cooling tower is a bit of an overkill as others said (due to latest developments on firmware and target environments). I will be adding a port of 5V+ and GND with a simple JST-XH connector just in case though

I leave it to Pierros to decide whether that would work or not. My way of putting together PC components involves switching on the power and then watching closely whether I see smoke or sparks somewhere.
I had a slight wiring mishap a few years ago and as it happened, my wife came into the room as the motherboard was literally sending up smoke signals.
I still have not lived that one down, that is a favorite story of hers whenever the topic of any conversation drifts into computers and electronics.

As for the Odroid being snappier, I think you have put your finger on the money. It's the eMMC that makes all the difference. I am booting my Pi4 off an SSD and the difference between that and booting from an SD card is also pretty stunning.

Read More...

jerry wrote: Anyone able to guess if the hat alone would fit onto a Odroid-N2 without modification?

https://www.hardkernel.com/blog-2/odroid-n2/https://www.hardkernel.com/blog-2/odroid-n2/

Robomort wrote: Active cooling is probably not required.
The RPI foundation have recently released a new firmware for RPI4 with better thermal management.
There are passive cooled cases which rival active cooling now available.
Ambient temperature outside at night works to reduce heating.
Finally, active cooling adds bulk and complexity.

Adding to my last post, Pierros, if you think that would be feasible, then I would suggest including a ground and a +5V pin on the BOTTOM of the board, to allow for the direct connection of the tower cooling fan (without having to run the wires around the HAT board and connect them to the pins on top).

Read More...

"All well and good but would not work on what this thread is about"


I'm not so sure, it just might be possible. That's why I showed the image with my current cooling solution.

I agree that with the conventional HAT design, which sits directly on top of the Pi board this would not work. That would fatally interfere with the cooling, whichever way you try to cut it.

However, this tower is hands down THE BEST cooling solution for the Pi4 (check out Christopher Barnatt's video on this cooler and how it compares to other solutions: www.youtube.com/watch?v=e6mWImsF9iI )

So I thought it might be worth exploring at this early stage, whether the AstroHAT can be designed in a way that allows incorporating this top of the line cooler for the RPi4 into the assembly.

I just think that might be possible, all that is required is to add some connection adapters that allow it to be moved up above the cooler. The 3D designs can easily be modified to make a case that incorporates the HAT with the cooler sandwiched in between the HAT and the Pi4 board and forming essentially a wind tunnel the cooling air is being sucked through, thus cooling the Pi4 and the HAT at the same time.

I would LOVE to have that construction on my rig. At the moment, I have 3 power lines running up the rig, one for the 12V needed to run the mount and the dew strips, one to power the USB hub and one to power the RPi4. If I could replace that with a single power line running to the HAT/RPi4 and everything else being powered off that, that would be ideal.

Read More...

AstroNerd wrote: Whatever is decided, it needs to be able to have the option of cooling the rpi, as with the rpi4 it gets very hot..so would need the room for a fan or at the very least a large heatsink...

Yes, that is what I proposed, essentially.

Just program the scheduler and the guide module to IGNORE the DEC swap command when "Always Recalibrate" is selected. Then the problem would not occur with those mounts that do not detect pier side. With the ones that do, just don't select "Always recalibrate" and all should be fine.

All we need then is a list of those mounts, one way or the other.

Read More...

Exactly my experience with the iOptron SmartEQPro+, which is also using the CEM60 driver.

I was prepared to accept that I was the only one who was seeing ghosts. I am glad to see that there is another Vampire Slayer joining the team now!

Read More...

Thanks, Chris and Wolfgang,

I'll check those parameters. It is true that the iOptron SmartEQPro+ mount has a pretty bad periodic error, which unfortunately makes large correction pulses necessary, but I believe that should only come into play in the RA axis. Since I am using a wide-field scope (250mm focal length) and short exposures (60s), drift in the DEC axis should be minimal. So I will try next time to just guide only in RA and turn off guiding in the DEC axis in the guide module. That should still result in round stars and make little difference to the framing as long as my polar alignment is adequate.
The argument against Chris reasoning that the declination of the second target (NGC2023) plays a role is that I had no problem collecting about 150 well-guided frames AFTER I just turned off the scheduler and restarted it, this time with DEC swap disabled. The target was still the same, nothing in the mount setup had changed, the only difference was that I stopped and restarted the scheduler. Calibration steps and all other parameters remained the same. Therefore, the mount and the default guiding parameters were perfectly adequate to guide well at the low declination levels.

And, Chris, the mount DID wander very rapidly off position. By the time I caught it, it had migrated almost all the way down to M42, so almost 3 degrees off its original position.

Read More...