Raspberry Pi 3 Model B+ problem !

[stash_old]

11 hours ago, halli said:

Ah thats great thanks Radek I was wondering whether there was a command line for downloading  it !   

The reason why I was trying to fix the firefox browser was to use it to download the astrometry files ..........

Hopefully I will try the offline solver out after I have performed the download  soon - looks like there may be some clear skies in the next couple of days ! 

You dont need clear skies to test it - just use the "load and solve" option with an existing image.

IMHO always test ,were possible, before doing "it" for real.

[stash_old]

12 hours ago, RadekK said:

Absolutely! It is your topic, I'm just a guest here ? One correction though - original place for index files is  http://broiler.astrometry.net/~dstn/4200/

You can either download them with firefox (version distributed with Ubuntu Mate is broken, as already discussed) or you can use command line (I know you either like it or hate it ? )

cd /usr/share/astrometry
sudo bash
wget http://broiler.astrometry.net/~dstn/4200/index-4211.fits

 

Release 3.0.0 of kstars/ekos allows the index files to be downloaded by just ticking the check box in Astrometry module / Index files option - this now downloads the files correctly - something that didn' work before 100% of the time due to permissions/timing I believe . A very simple mechanism ?

[halli]

 

25 minutes ago, stash_old said:

Release 3.0.0 of kstars/ekos allows the index files to be downloaded by just ticking the check box in Astrometry module / Index files option - this now downloads the files correctly - something that didn' work before 100% of the time due to permissions/timing I believe . A very simple mechanism

Thanks Stash I'll take a look at that.  

30 minutes ago, stash_old said:

You dont need clear skies to test it - just use the "load and solve" option with an existing image.

IMHO always test ,were possible, before doing "it" for real.

Understand what you say about testing and I agree  - best not to waste more of clear skies than you need to !  The trouble I find with testing under clear skies is there is always a pressure to complete it and to get a full imaging rig up an running always seems to have its niggles which can delay things and then the clouds roll in ! Also its cold this time of year ............ 

I have been using a windows version of Kstars on my PC to remotely control the Pi but I noticed that release 3.0.0 of the windows version does not appear to allow offline solving for some reason which is a shame.  

[fozzybear]

18 hours ago, RadekK said:

It is part of KStars/Ekos, but you can also use it from command line. If you prefer the latter just install astrometry by running:

sudo apt install astrometry.net

add index files and then play with solve-field command (see examples in the astrometry readme file - linked above). It can do magic, including annotating your images with detected objects.

The easy way is to use KStars/Ekos - plate solving is located on Align tab. The easiest way is to use online plate solving and upload your images for processing - http://nova.astrometry.net/upload

Radek

cheers for the update one error I made is that I did not add it under aux in control panel that's why I could not find it, now it is loaded but won't solve yet under align icon can't do anything (click on anything) also kstars 3 on my windows 10 kept on crashing when talking to the rpi ( ran troubleshooter for windows) and running in compatible mode seems to keep it alive for now

Also on ekos there is a tab to download the index files in the astrometry options nice and easy

Andy

[fozzybear]

5 hours ago, stash_old said:

You dont need clear skies to test it - just use the "load and solve" option with an existing image.

IMHO always test ,were possible, before doing "it" for real.

when I look at the option above are you referring to the rpi or pc as on the rpi in align all options are shadowed out and can't do anything?

[RadekK]

You don't need to add astrometry driver to your profile to get it working. This driver is used only if you have your index files and astrometry on separate machine.

If your Align tab in Ekos is greyed out, you either don't have your mount or CCD properly configured in the profile. Could you upload a screenshot of your Ekos profile so I can give you some directions?

[stash_old]

9 hours ago, halli said:

I have been using a windows version of Kstars on my PC to remotely control the Pi but I noticed that release 3.0.0 of the windows version does not appear to allow offline solving for some reason which is a shame.

Will have to be wary of using "PC" - doesn't describe what you are using O/S wise. Do you mean you are using Kstars on Windows O/S or Linux on a PC. Kstars on a Linux PC (even when parts are running on a remote PI) does allow local plate solving (On the Linux PC) so long as its installed and works very very well. ?

Windows Indi platesolving  I have not done and I think it is not quite as straight forward maybe Radek can throw some light on the "How". IMO Windows INDI is NOT supported really in the same way ,as Linux, at all and Windi (the only Windows server - equal to indiserver on Linux -  just gives you access to Ascom devices)

It appears ANSVR is the only option https://www.indilib.org/forum/wish-list/2462-offline-plate-solving-on-windows-kstars.html

[stash_old]

4 hours ago, fozzybear said:

when I look at the option above are you referring to the rpi or pc as on the rpi in align all options are shadowed out and can't do anything?

Have you got a mount and camera defined in your test profile and are they connected - even using telescope/camera simulator should allow Align to work - just remember to fill in the telescope details to match you own telescope when you took the image you are using for testing.

[RadekK]

Oh, thanks for keeping it sane @stash_old I've just realized that @fozzybear might use KStars on Windows... So to comment on that - local Astrometry and plate solving is not available on Windows by default. You can make it work with ANSVR though. In such a case you need to setup your local astrometry server and use astrometry driver to plate solve remotely (which really means localy but with your own server running ANSVR). Another option is to use online astrometry, which works independently of your platform.

[halli]

Tried astrometry just recently using the Kstars/Ekos on the Pi with Astroberry and it worked fine with the offline solver now I have downloaded the missing 4211 index file !  I was using the CCD and telescope simulator with astrometry as aux 

However you need to configure your CCD resolution and pixel size as per your real CCD and also the telescope for aperture and focal length as Stash mentioned above or otherwise the range of index files chosen will be wrong.  

[stash_old]

I will be shot for this but IMHO Using Kstars/Ekos under Windows ,at this time, is a waste of time. Better to run Linux as a sub system under Windows and install Kstars/Ekos or just VNC to RPI running it all. Or better run GRUB2 and dual boot(Linux and Windows) so you get the full CPU speed without the emulation problems - and can keep Windows. I did say IMHO ?

[fozzybear]

28 minutes ago, RadekK said:

You don't need to add astrometry driver to your profile to get it working. This driver is used only if you have your index files and astrometry on separate machine.

If your Align tab in Ekos is greyed out, you either don't have your mount or CCD properly configured in the profile. Could you upload a screenshot of your Ekos profile so I can give you some directions?

Damn, after all you just answered my questions as eqmod kept getting connect errors in ekos, something else to figure out cheers CCD works ok

[fozzybear]

28 minutes ago, stash_old said:

Will have to be wary of using "PC" - doesn't describe what you are using O/S wise. Do you mean you are using Kstars on Windows O/S or Linux on a PC. Kstars on a Linux PC (even when parts are running on a remote PI) does allow local plate solving (On the Linux PC) so long as its installed and works very very well. ?

Windows Indi platesolving  I have not done and I think it is not quite as straight forward maybe Radek can throw some light on the "How". IMO Windows INDI is NOT supported really in the same way ,as Linux, at all and Windi (the only Windows server - equal to indiserver on Linux -  just gives you access to Ascom devices)

It appears ANSVR is the only option https://www.indilib.org/forum/wish-list/2462-offline-plate-solving-on-windows-kstars.html

PC running win 10 pro and running kstars on that then accessing rpi  will try on my lappy running linux

 

[RadekK]

You can use windows and access Astroberry Server as a remote desktop over VNC or a browser. It's slower but this way you run everything in linux environment and use your windows (or any other system) as a keyboard and screen.

BTW. To all of you playing with plate solving - remember to set bin2 or even bin4 when capturing image for solving. It makes your life easier

[halli]

So near and yet so far !

Ive just spent some time over the past two nights with clear skies playing around with Kstars/Ekos and the raspberry Pi controlling my kit.   I thought I would share my experience.

Firstly my imaging kit comprised a 130pds scope with ZWO ASI 1600mm-c , Atik EFW2, NEQ6 and Altair GPCAM for guiding.   

I have been able to connect the Pi via some TP-Link powerline LAN extenders from my garden to my home router.  In order to do this I have found that you need to turn the WiFi permanently off - or at least I had to ! 

The Astroberry IP address needs to be obtained from the connected device table from the router.  This can then be used in a browser to connect to the Astroberry image in the Pi .  It appears to offer quite a stable remote connection.

The ZWO has a USB hub and the EFW2 and GPCAM are connected to this with one USB connection from the ZWO to the Pi.  The NEQ6 was conneccted using EQMOD over Bluetooth.  I had previously spent some time ensuring all the kit connected to Ekos ok and was ready to be used in anger.  I also plugged a USB stick into the Pi to save images on.   

My aim over the last couple of nights was to test the plate solver , guiding, and image capture capability of the rig using Kstars and Ekos.

From a user perspective I found the control console approach of Ekos where all required functions for mount setup, control and image capture which were presented on a separate tab from a single entity and also their simplicity to be excellent.   However the  settings and config the INDI control panel offered  sometimes overlapped with those of Ekos which was a little confusing.   The integration of this within the Kstars planetarium was also a very good concept.   However this also had a downside when it came to performance as highlighted below.  

Unfortunately I found real time performance of the system unreliable and patchy.  Sometimes I could go through the  astrometry solver,  image preview, guider startup ( I used the internal guider)  and image capture sequence without a hitch although this was the exception.  I managed on one occasion to complete  an image capture sequence of 20 LRGB images of M81 and M82.   Usually however during the workflow Kstars/Ekos would crash and disappear without warning or some driver or another would crash or the Indi server would disconnect for no reason.  All very frustrating !   I think some of it was my fault in pushing things a bit too hard and having too much going on at the same time  - I guess the control console type presentation  was a victim of its own success in this respect as it was all to easy to jump from one function to another .   I felt the CPU in the Pi was perhaps operating at the edge of its capability when put under stress by going through some of the image capture routines.   Certainly I was disappointed as I feel with things like they are it is not useable as a reliable controller of my imaging rig and wouldn't know how to put things onto a more stable footing.   Certainly quite frequently the  Kstars/Ekos software would crash in the middle of an imaging run and this was very frustrating  - and as Ekos and Kstars are on one platform when they crash you loose everything ! My style is to set everything up to do an imaging run and then go to bed,  so one thing that is paramount is reliability !!

I also tried using Kstars/Ekos  on windows on my desktop to interface to the Pi just operating as an INDI server rather than just using VNC over the LAN to perhaps reduce some of the load on the Pi and although I connected to everything pretty well -  as far as real time performance - if anything this was even worse ! 

Not sure where to go from here with Ekos/Kstars  - perhaps try and establish whether there is any pattern to the crashes, but they appeared pretty random to me.  My rig isn't anything unusual and  I dont think it was just my finger trouble.   Even finger trouble shouldn't have caused software to just crash and close down.      

I really do not want to give up on this as it has so much potential for the user and is an excellent concept.

I would really appreciate knowing what other people's actual experience is of using Kstars/Ekos on the Pi in anger for imaging  - in order to judge whether there is something basically wrong with my approach and whether there is something I am overlooking.

Sorry its a bit of a brain dump ................... 

 

 

[kens]

Nothing you said is surprising. Running everything on the Pi is a big ask. So running Kstars/Ekos on your Windows machine is a better way to go. That is how the system is supposed to be used. I'm interested to know where you encountered performance issues using Ekos on Windows. Was it during image download? If so, make sure you are saving your images to local rather than the client so you save then to your USB stick rather than transferring over ethernet.

I don't use a Pi - had one but upgraded to a faster device with USB3. I run PHD2 on the device to get best performance as there is no guide image download over the network and I can use the native ZWO driver.

The main downside to running Ekos on the client is that it doesn't like network dropouts. I normally connect over wireless but the dongle drops out from time to time and I need to restart Kstars. At least PHD2 keeps running and INDI stays connected.

The INDI control panel is not really meant to be used on its own. The layout is determined entirely by the driver (and whoever wrote that particular driver) so there is not a lot of consistency from device to device. It is made available so you can use non-standard settings but to do that it has to show you everything available whether you are interested in it or not. 

Another thing to watch for is that you are connecting everything to the Pi USB ports. Given that Bluetooth, Ethernet and Wifi also connect internally through USB you might be overloading that part of the system. Are you seeing the lightning flash on the top right of the screen? That indicates low power. That could be why you needed to disable Wifi for things to work. A powered USB hub would be a better way to go. Also, how are you powering the Pi? I use a UBEC to convert 12V to 5V and connect it straight onto the GPIO port.

[stash_old]

4 hours ago, kens said:

Another thing to watch for is that you are connecting everything to the Pi USB ports. Given that Bluetooth, Ethernet and Wifi also connect internally through USB you might be overloading that part of the system. Are you seeing the lightning flash on the top right of the screen? That indicates low power. That could be why you needed to disable Wifi for things to work. A powered USB hub would be a better way to go. Also, how are you powering the Pi? I use a UBEC to convert 12V to 5V and connect it straight onto the GPIO port.

Ken is right you should not be running,using CCD camera's, without a powered HUB (a good one) and the power supply MUST be +3amps (and not just peak). I use DSLR but that comes with its own power supply . He is also right that using the Ethernet wired port is fighting for resources with the USB ports (its built that way) - the Wifi does not share the same BUS as the USB/Ethernet.

You will not see the "lightning" icon if you connect VNC (silly really) only shown when connected via HDMI but it does show up in the logs - if this is coming up then you have an under powered RPI.

As Ken quite really says you are asking a lot to run CCD at full rate on a £32 PC - IMHO.

TPLink power line is a very iffy approach - its effected by too many things (power spikes) and never gets anywhere near the rate quoted - run a Ethernet wire or use Wireless.  

Maybe stop and re-evaluate your set up and ask "will this work for me" - as I have said before Indi is immature. 

@Ken - you must be having better luck than me Up Core USB3 is very temperamental  in my experience - it has caused a few crashes even on Windows 10 especially when not using a HUB (so might be the same powered Hub problem)

[halli]

Thanks Ken and Stash for your valued input - it is appreciated.  I guess I will persevere and try a few things to try and improve performance.

7 hours ago, kens said:

Also, how are you powering the Pi? I use a UBEC to convert 12V to 5V and connect it straight onto the GPIO port.

Firstly the PSU  - I guess I will obtain the recommended Pi PSU just to rule this out  - your UBEC idea also seems a good way forward

2 hours ago, stash_old said:

Ken is right you should not be running,using CCD camera's, without a powered HUB (a good one)

Wrt the powered USB hub:  The ZWO camera contains its own powered USB hub so I believe I fulfil this requirement - I only have one USB lead attached to the Pi so dont see how I can improve on this.   

Good thought on the use of the LAN using the same bus as the USB - I hadn't realised this.  I think I can connect via wireless  - just thought the LAN extension would be better even if using powerline  - but it may not be.  I will try it out with the wireless connection.

7 hours ago, kens said:

I run PHD2 on the device to get best performance as there is no guide image download over the network and I can use the native ZWO driver.

I agree that using PHD2 externally is the best way forward for guiding as at least there is another bit of software which will maintain connectivity to the mount in the event of Kstars/Ekos crashing ( I am assuming !) .   When this happens the EQmod mount normally disconnects, tracking is lost  and the target drifts away from centre and needs to be realigned when it is restarted (very frustrating).    

In fact I was going to use PHD2 and managed to get it to work previously and the performance of the guiding was excellent.  Unfortunately I couldnt get the GPCAM camera to connect to it during the last couple of nights hence I used the internal guider.  The PHD2 performance was one of the things which spurred me on to put the effort in to getting the Pi set up to work as I felt that a Linux approach was better than windows for this type of real time control.

I take the point about the importance of the network connection when using a client/ server approach with a separate Kstars instance on windows. 

7 hours ago, kens said:

I'm interested to know where you encountered performance issues using Ekos on Windows. Was it during image download? If so, make sure you are saving your images to local rather than the client so you save then to your USB stick rather than transferring over ethernet.

I was trying to download the images to my desktop when using the windows Kstars (to save downloading them from the USB stick !) so that could have been a contributory factor

I see you are both feeling as I that perhaps this is all too much for a Pi however there are a number of commercial boxes eg stellarmate, Atik Air, ASI air which appear to be based on the Pi ! Perhaps the software is better  - who knows.

Anyhow it was good to have the benefit of your experience and as a result I will make several adjustments to the way I am doing things and see what happens.

 

 

[stash_old]

19 minutes ago, halli said:

I see you are both feeling as I that perhaps this is all too much for a Pi however there are a number of commercial boxes eg stellarmate, Atik Air, ASI air which appear to be based on the Pi ! Perhaps the software is better  - who knows.

Thats why ZWO only allow certain USB3 camera's (theirs) and still use the handset (hear that may change). All of them are based on Linux Indi and I don think the base software is much different even if  the "shop front" software is. But might be wrong. The memory (lack of) ,no USB3 ,No being 64bit (if it had the memory) ,power support limitations are caused by design (/price limitations- fine for what it was intended for - learning. I am no knocking it (PI) I think its great - just "horses for etc". 

To add to your list Eagle just never found anyone locally who has used them - like all things you dont find the problems/limitations until you have one.

[kens]

7 hours ago, halli said:

Wrt the powered USB hub:  The ZWO camera contains its own powered USB hub so I believe I fulfil this requirement - I only have one USB lead attached to the Pi so dont see how I can improve on this.   

As far as I know the USB hub on the ASI1600 is not powered from the 12V power -that is solely for the cooler. 

8 hours ago, halli said:

Good thought on the use of the LAN using the same bus as the USB - I hadn't realised this.  I think I can connect via wireless  - just thought the LAN extension would be better even if using powerline  - but it may not be.  I will try it out with the wireless connection.

My experience is that LAN is way more reliable than Wifi. Wifi on Linux in general is problematic in terms of which chipsets work, don't go to sleep etc... Having said that I've found the Pi wifi to be amongst the ones that work fairly reliably. But it is going to be slower than the LAN. Network speed is the main issue with the ASI1600 with its 32MB files. At gigabit/USB3 speeds the transfers are close to instantaneous, at 480Mb/s (USB2) it takes a few seconds, at 100Mb/s you are watching the clock waiting for the download to complete and any slower you start to wonder if anything is working. I prefer to use Wifi despite the problems so I focus, preview and platesolve at 4x4 binning to cut down the download times. And I save the files to the UP Core (called local on EKOS) and download at the end of the session once I can connect the LAN. If I want to check the images during the session I use VNC and run Siril on the UP Core to view them. 

7 hours ago, stash_old said:

All of them are based on Linux Indi and I don think the base software is much different even if  the "shop front" software is. But might be wrong.

Certainly StellarMate and ASIAir are INDI based. With the ASIAir what you are paying for (IMO) is the client software running on iOS. If you aren't interested in that you may as well get a StellarMate or roll your own. AtikAir I'm not sure about but I think it uses native drivers only and operates just the camera.

8 hours ago, halli said:

In fact I was going to use PHD2 and managed to get it to work previously and the performance of the guiding was excellent.  Unfortunately I couldnt get the GPCAM camera to connect to it during the last couple of nights hence I used the internal guider.  The PHD2 performance was one of the things which spurred me on to put the effort in to getting the Pi set up to work as I felt that a Linux approach was better than windows for this type of real time control.

The GPCAM on Linux has some problems. It is a rebadged Toupcam and the Linux drivers are not very good. In fact it was only recently they produced a Linux driver for ARM devices. The way they distribute the Linux driver is eyeball rolling stuff. Getting it (Toupcam) to work in PHD2 and INDI has been a bit of a struggle but I see it has been recently re-enabled. PHD2 has separate drivers for  Altair and Toupcam whereas on INDI they have converged. There may be an opportunity on PHD2 to converge them and pick the best bits out of both to get something that works well. Meantime you might want to see if the native Toupcam driver in PHD2 works with your GPCAM and failing that try the INDI driver.

[halli]

Thanks Ken all good info.

I had another session with the rig this afternoon taking images of my scope dust cover ! 

I was using Wifi this time and surprisingly I managed a fairly long image capture session and it was pretty stable.  This is quite encouraging . 

I have normally used the powerline LAN extenders in the past for using team viewer with my laptop  because the wifi is a bit weak at the bottom of the garden and the LAN was quicker.  It looks like the Pi is able to connect and perform as normal  even though the wifi signal is not that strong.  It may be that the Pi was being upset by hanging  70 feet of copper power cable from its LAN port and the crashes were due to some form of noise spikes .  Who knows, I guess time will tell but for now I will stick with the WIfi as the performance appears to be adequate for the moment.  

32 minutes ago, kens said:

I prefer to use Wifi despite the problems so I focus, preview and platesolve at 4x4 binning to cut down the download times.

 I have also found that the solver works fairly well at short exposure and high binning.  This surprised me as I found that Astrotortilla was very fussy  in this area and I needed to use the lowest gain with a longish exposure to get it to work.

I would really like to get PHD2 working reliably and need to spend some time concentrating on getting the GPCAM to connect.  I dont understand why I got it to work previously and now it doesn't want to know.  It connects ok every time to Ekos and works on the internal guider so it is very frustrating.

I have ordered the Pi recommended supply but fingers crossed the stability I experienced using wifi this afternoon will continue. 

 

 

[kens]

4 minutes ago, halli said:

I would really like to get PHD2 working reliably and need to spend some time concentrating on getting the GPCAM to connect.  I dont understand why I got it to work previously and now it doesn't want to know.  It connects ok every time to Ekos and works on the internal guider so it is very frustrating.

The Ekos internal guider uses the INDI driver. PHD2 can use either the native driver or INDI and could possibly use either the Altair or Toupcam drivers. Can't speak for the Altair driver but the Toupcam driver in PHD2 operates in what is called trigger mode where each exposure is triggered by the software. The alternative is streaming mode which sends a constant stream of video images. PHD2 prefers to use trigger mode for all cameras now as some issues were found with streaming mode with backlash compensation and long corrections causing streaking of the guide star. My personal preference was for streaming mode but the software needs to work for everyone. I suspect that the internal guider uses streaming mode. In PHD2 you could try using the INDI driver (IND Camera) and select the option in the settings for "Camera does not support expsoure time". This should force streaming mode. Can't guarantee it will work but its worth a try. If you can reproduce the connection problem then post on the PHD2 support forum with your debug log.

[fozzybear]

13 hours ago, stash_old said:

I use a UBEC to convert 12V to 5V and connect it straight onto the GPIO port

I am interested in this yet on the rpi forum this bypasses the thermal fuse built into the rpi i have a couple of lm2596 buck convertors and was going to put a 7805 regulator in as well, also a fuse just in case

albeit the 7805 is rated to 1 amp i'll fit a heatshield as well, so anything over 5 volts is protected. what do you think

[kens]

The Hobbyking UBEC I use is regulated and has reverse polarity protection. I think a fuse on the 12V side of the UBEC should be sufficient. And care in connecting it the right way to the GPIO.

[stash_old]

15 hours ago, kens said:

My experience is that LAN is way more reliable than Wifi

Normally yes but not using the electricty cables - e.g. Power Line is not and does vary greatly in speed - also prone to power pikes causing interference. I used a number of TP Power Link products over the years - yes they work but give more problems than its worth. If you wont hire wired lan

 

13 hours ago, fozzybear said:

I am interested in this yet on the rpi forum this bypasses the thermal fuse built into the rpi i have a couple of lm2596 buck convertors and was going to put a 7805 regulator in as well, also a fuse just in case

albeit the 7805 is rated to 1 amp i'll fit a heatshield as well, so anything over 5 volts is protected. what do you think

run a cable ?

I use these https://www.aliexpress.com/item/DC-DC-Converter-Buck-Module-Converter-12V-to-5V-24V-to-5V-10A-LED-Power-Supply/32302609888.html?src=google&albslr=221515816&src=google&albch=shopping&acnt=494-037-6276&isdl=y&slnk=&plac=&mtctp=&albbt=Google_7_shopping&aff_platform=google&aff_short_key=UneMJZVf&&albagn=888888&albcp=1706973087&albag=65008162765&trgt=296904914040&crea=en32302609888&netw=u&device=c&gclid=CjwKCAiAqaTjBRAdEiwAOdx9xmHpWsYu4Qir3BXXrqLX8kMdqZICjKw06ea11x3Lh1jkiKcE7ztltRoCA2MQAvD_BwE&gclsrc=aw.ds

Never had a problem with power  on RPI's or Up Core and I dont go thru and dont see any advantage, IMO, to using  GPIO. Used the smaller brother,see below, of the above (12v - 5v 3amp)  for RPI's (1,2,3 and zero) ,camera lens dew heater plus other 5v devices for 3yrs not a problem. But each to their own.  And yes I know Ubec were used by RC Model enthusiasts. 

https://www.ebay.co.uk/itm/New-DC-Converter-Module-12V-To-5V-3A-15W-With-Dual-USB-Cable-For-Car-GPS-MP3-UK/143056360196?hash=item214ed2d304:g:8EMAAOSwM6FcGF6D:rk:12:pf:0

15 hours ago, kens said:

At gigabit/USB3 speeds the transfers are close to instantaneous, at 480Mb

Neither of which the PI has and that's what these guy's are using - at present ?