IOptron IMate Astronomy Control box - review

[William Shaw]

Version 2.6, February 6: Links to code to allow switch to home wi-fi (linux knowledge and care needed)

 

I got one of these from Altair in mid December and have been fiddling with it since then Corrections and useful info very welcome.  Folks should be aware I am mostly Mac and I-device biases so my comments will lean that way, though the NoMachine client is also fine on my Windows update. 

 

I've had help getting going and want to acknowledge Vallo Giu and Gustav Old Lundby on the IOptron FB page, and Kevin (Tech2) and John (Tech1) on the IOptron support team. 

 

Summary

 

I'm happy with it now I've figured out a few points on USB and power. For many people the RPi3 implementation may seem underpowered and it took me a little while to stabilise operation with my IMX-571 based Altair Hypercam 26C. It should be noted that Altair recommend i5 or better for that camera so this is pushing it!  Downloads from that camera at full resolution take about 6s to complete but there is a setting in KStars that can mitigate matters (see below). It's not a control unit suitable for many-short-exposure work. But it works fine and is stable with that camera. It would be better suited to lower pixel count sensors like the IMX533 cameras. I would't try to use it on a 60MP+ unit. The KStars user interface needs a bit of time investment and is not super-responsive on the IMate O Pi3 LTS, but once a capture sequence has started it is fine modulo how you feel about image download speed. The unit is low priced and most importantly ships with INDI drivers for a multitude of devices from device manufacturers. So none of the nonsense about having to use a tied brand. My test rig contained gear from Altair, IOptron, Primaluce lab and ZWO. It ships with KStars 3.6.7 and IOptron say they will curate updates - there is a bug with 3.6.7 as the camera settings are forgotten when you log out!  INDI drivers work well and so far I've not had any of the "which port do I guess next" that I often get with ASCOM. 

 

I've used it for a complete imaging run including ipolar on my phone for PA, plate-solving goto, autofocus and capture. Also to take flats, darks etc. It does the job provide you have got secure USB links done the right way and allocated power sensibly. 

 

Current issues remaining are (i) stability with certain cameras  - Vallo was having trouble with his ASI 2600 Duo; (ii) using it as a client of your home wi-fi - I can use its self-generated wifi just fine and plugging in ethernet is fine, but there is no simple built-in switching app. I've now made some progress writing some terminal commands to connect to my home wi-fi, and as long as you are familiar with linux terminal operations, you can try out the ideas here:

 

 

(iii) the meaning of the port labelled "USB 3.0" - the camera does not download any quicker than it does on the other blue port. The Orange Pi 3 LTS being used by IOptron is specced as USB3.0 but I do not really know what use it is; (iv) being able to store a precomputed camera calibration in the phone based ipolar app (v) forgetting camera settings; localisation problem needing command line intervention (vi) no nice text editor. 

 

For the phone-based ipolar, you might have to update the firmware on your ipolar camera to get the link to work. Details below. See below and the IOS Apple Store review if you have an iPhone or iPad to access it. 

 

Introduction

 

The IOptron page for it is at

 

https://www.ioptron.com/product-p/8480.htm

 

and in the UK you can get it from 

 

https://www.altairastro.com/ioptron-imate-astronomy-control-box-13421-p.asp

 

I encourage folks to read the support documents throughly. I'll be upfront and say that I am a bit rusty on KStars/EKOS and also made some mistakes from not reading the docs properly before setting up! Some useful correspondence with IOptron tech support has been helpful and I am grateful to them for putting me straight on a few issues already. 

 

A quick summary is that it is an Orange Pi 3 LTS computer with self-generated wifi, 2G RAM, 64-bit ARM, 3 USB ports, one of which is said to be USB3, 3x 12V DC outputs. It has internal 32G flash memory and a slot for a 64G micro SD card. Those cards are really cheap online and I got a 3-pack with an adapter for normal size SD cards. It is preloaded with KStars, EKOS and INDI drivers for an astonishing number of hardware manufactures and device. As shipped it comes with a finder scope dovetail, and the intruiging iPolarServe tool that integrates with a new ipolar mobile app for iOS and Android devices. I got the iOS version (£2.99).  So to be clear there are NO significant brand constraints on what hardware you connect, but you should check that INDI drivers are available for what you intend to use. 

 

It ships with a stable release of KStars 3.6.7. You should note that IOptron have told me they intend to curate updates to the IMate software including KStars updates, so if e.g. you want to update to 3.6.8 you probably need to wait for IOptron to make it available. A few of us tried to update using the standard KStars terminal scripts (how to connect to web is discussed below) and they do not seem to work. 

 

What I am testing with

 

The initial deployment is to control the following gear:

 

IOptron GEM45 with ipolar

Altair Hypercam 26C OSC IMX571 camera. 

SESTO SENSO 2 focus motor

ZWO ASI120mm mini guide scope

 

and for flats

 

Giotto flat panel

 

I'm running dew strap power out of a separate controller  - a basic Pegasus dew unit. I also explored use with a CEM70G and found out some interesting things about ipolar in relation to that (See below). 

 

IOptron support doc links for the IMate and KStars 

 

https://www.ioptron.com/v/Manuals/8480_iMate_Manual.pdf

 

https://www.ioptron.com/v/manuals/The_Kstars_Handbook.pdf

 

Connecting the iMate to the gear

 

USB stuff

 

Please note the USB port labelling and colours. There are two blue ports and one white port. One of the blue ports is labelled USB3, one is USB2. You can probably guess what I did and I wasted some time trying to figure out why my USB3 Hypercam was coming up as USB2. I thought blue = USB3. Anyway don't do what I did.

 

The USB port labelling is decidedly odd though. The RPi3 does not AFAIK support USB3 at all, but the Orange Pi 3 LTS used by IOptron apparently does - see here:

 

http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/orange-pi-3-LTS.html

 

However, the download speed through either blue port is identical, despite the Orange Pi  3 LTS spec claiming it can transfer data up to ten times faster. But operation of my camera seemed to be more stable through the USB3 port and it was recognised as a USB3 device rather than USB2 using the other port. Tech support has been asked for a clarification. 

 

Given I have four USB devices and three ports, I am experimenting with which works best channeled through the hub on my camera. The guide cam seems happiest.

 

The IMate, albeit subjectively, seems so far to be more fragile than my Gaius-S and i5 MIni PC NINA rigs when it comes to tolerance of and recovery from a USB connection problem. It really is necessary to have good quality snug fitting cables. I did have some crashes when first using it but I traced those mostly to either a USB connection fail or power.  The security of the connection to the mount is very important given the relative motion of that one link - that failure point has also caused guiding to stop working on my Windows mini PCs - here it can need a full restart.  

 

Power stuff

 

This I've found to be important for stable operation. I'm powering my mount separately so as not to have a cable coming down to it, and this also lowers the load on the IMate too. Dew control is managed by a separate simple controller.  

 

The DC outs are all 5521 connectors like the DC input. Recent IOptron mounts tend to use 5525 so check your cables!

 

I use two of the IMate DC outputs to  power the Hypercam and SESTO focus motor.  Note that the three ports are NOT the same when it comes to current provision. They are all 5521 connectors like the DC input, but DC3 is always on and provides up to 3A. DC1 and 2 go to 2A. I strongly recommend that you check the ampere requirements of your camera. And I suggest that you plug a cooled camera into the DC3 output if you use the IMate to power the camera. That together with the USB3 port for the camera produced a stable rig for me. 

 

You might have to experiment a bit here and think about how you use batteries when in the field away from mains power.

 

I should point out that I've gone upmarket for batteries and use a high power unit with multiple DC (car and 5521) outputs as well as AC I happen to use an Ecoflow recommended by PLL for field work with their Eagle units, but Jackery etc make similar ones. So if needed I can use a 19V pc running off its AC brick as well as make my coffee. But you do not need to spend a lot to provide power off grid.  If you are using a single smaller unit then think about how to split the outputs first. Before I got the Ecoflow I used a couple of Tracers - one for mount+dew, the other for everything else. 

 

Connecting to the iMate - wifi and NoMachine

 

So far so very good. 

 

The self-generated wifi works very well and produces a strong wifi signal. It just works and I could connect from inside my house to the mount several metres away. 

 

I have also made the iMate a client of my house network but out of the box AFAIK you can only do this with  ethernet. If you plug in an ethernet cable the ethernet takes over and you can use that network. I have now got it the iMate switching to my home wi-fi but it needs some command-line faffing for now - here is the link again:
 

 

 

But the ethernet works fine and then you can connect the imate to the outside world. (note comment above that IOptron will manage KStars updates in due course). NoMachine can of course be run over ethernet. 

 

The user interface connection is using NoMachine and this is easy to get working. I've run the iMate so far from my iMac, a  Windows laptop, my iPhone and a recent iPad Air. 10/10. You might want to investigate how best to optimise screen resolution on your own client. It works great on the iPad Air. No Machine has the nice feature that it displays the machines that are available to use so you can just click on the iMate and get going.  It's easier that Windows Remote Desktop, where you need to get the machine name spot on or use an IP address. (for Mac users "spot on" under RDP means connecting to eg "My Astro PC" as "My-Astro-PC.local" - none of that with NoMachine!). 

 

Job1 once NoMachine started - Setting time zone and time. 

 

Doing this first with a bit of care is helpful to avoid issues later. First set the time zone with the Orange Pi tools. Then set the time in that time zone with the imate set time app under the "Education" menu along with KStars etc.   if you don't do things in this order it can get very confusing - my Mate shipped on PST. As far as I can tell between sessions with the power off iMate will remember the time zone but not the time.  

 

Note that if your iMate is connected to the internet (for now that is via ethernet) the time does NOT need to be set manually as the iMate will connect to an internet time server within a few seconds and the correct time will show at the top right. Probably uses NTP but I didn't well on it. 

 

Job 2 - keyboard  localisation

 

In starting to fiddle with the setup using a terminal window, I discovered that I had the wrong keyboard mapping. Sadly NoMachine abdicates responsibility for any kind of localisation or other keyboard management between your terminal machine and the linux server, saying it is server side setting. Furthermore, at least on my copy, the Orange Pi config tool to sort out the keyboard doesn't run properly. My unit shipped with US PC keyboard config, as I saw when running

 

setxkbmap -query

 

in a terminal. So I ran (after some searching for what to do)

 

setxkbmap gb

 

and that set PC my keyboard to UK spec, at least in terms of getting key special characters like "~" correct, which is critical if you are trying to use online suggestions for linux spells to do stuff. 

 

You can run 

 

man keyboard -config

 

and look at

 

https://gist.github.com/jatcwang/ae3b7019f219b8cdc6798329108c9aee

 

to see a multitude of options for both country and keyboard size/type. "setxkbmap gb" has to be run each time I log on for now. I have not yet made it permanent. The instructions I found to sort that out, like adding that line to what looked like my login stuff in the ~ or $HOME directory, mysteriously failed. I also realised at this point that the IMate does not ship with a user friendly GUI based text editor, so I might sort that out before blundering about with vi(m) or whatever and bricking my machine. 

 

Just for another example, when I logged in to the IMate from my desktop Mac I also ran

 

setxkbmap -model macintosh

 

which got the special characters right. So with both that and gb the query runs as follows

 

imate@iMate:~/Desktop$ setxkbmap -query
rules:      evdev
model:      macintosh
layout:     gb
 

If you are going to fiddle around with a terminal and/or a text editor I strongly advise you to Invest a bit of time sorting that out as otherwise you will type gibberish. Given that I swap between MacOS, IOS and Windows clients to run the IMate you can appreciate I have entered a lot of gibberish early on. 

 

Polar Alignment with ipolarserve and the iOS app

 

See also the review(s) on the iOS App Store. 

 

This works by starting an app called ipolarserve which connects to the ipolar camera which makes ipolar available to the ipolar IOS app and (I think) and Android equivalent. When I first tried it on my CEM70G the ipolarserve refused to connect, but on the GEM45 it connected fine first time. So this is interesting and I should aad that using ipolar under windows the 45 had been more consistent also. Tech support told me that ipolar cameras should have the latest firmware to use ipolarserver, and to use this information to do it:

 

https://www.ioptron.com/Articles.asp?ID=350

 

With ipolarserve running fin, at least the first time I tried the GEM45 I was able to launch the ipolar app on my phone. On trying again on my first clear night I also had a connection failure with ipolarserv, which was fixed by installing the V2 ipolar camera firmware (see below). See below on this. Then all well again. 

 

But you should note that as things stand with this initial release you need to start the ipolarserv on whatever you intend to use as you session control client, but that the ipolar app it connects to runs off a phone or tablet. This makes sense in terms of going outside for an initial set up including PA, or whole session use of eg an iPad wherever. 

 

One nice feature I noted is that the IOS phone app can grab your location straight from the phone. I presume this is via the GPS chip. People thinking about using an iPad should note that the GPS chip, AFAIK, is only present on cellular models. I found that out when looking at Commander Lite a while back. 

 

Side issue - If you need to update ipolar firmware - and other lessons from the CEM70G!

 

With the 70G ipolar camera not being recognised by ipolarserve, I loaded the firmware update tool and that could not see the camera either. I then checked ipolar under Windows and that was flakey too in making a connection. So it became clear I had another issue. I'd read that repeated insertion of the CEM70 hex key to lock the RA axis while moving it (very handy feature) could potentially dislodge the USB connection to the ipolar. I undid the two grub screws holding the ipolar in place and looked at the USB connection. it did not look loose but I pushed it in very firmly and then tried the ordinary Windows app which then connected right away. I reinserted the camera carefully and tightened the grub screw (note that a camera recalibration is now needed by doing the position confirm routine - doing an average is a topic for another day). I then ran the firmware update tool. You need to **carefully** select the ipolar (and not the iguider) and try V3 first. That did not work but V2 did. After the update ipolarserve booted just fine (see pic below) and then my ipolar app on my iPhone could run the iOS ipolar. I think that after a firmware update only recent versions of the ordinary Windows app work (I'm on 2.7.3 now) and I need to check my Mac as well. 

 

So if you are not getting ipolarserve working you might have to update firmware and/or make sure the connections are secure. I had to do both. And do not do what I did in my haste and update the iguider firmware on the 70G with the ipolar firmware. I now have ipolar and ipolar 1.1 (FKA iguider) cameras. I'll sort that one out later - think it will be OK as Sharpcap recognised both! As already noted, the stability of my GEM 45 connection was also helped by doing the V2 firmware update. I could not get V3 to load on either ipolar. Under Windows ipolar 2.7.3 connected as before to the ipolar cams on both machines, as does now, ipolar serve. 

 

The iOS app in detail

 

Now to the iOS app. It's OK - good for a first version of the app perhaps. It has the nice feature of picking up the location from the GPS chip in the phone (or iPad if you have a cellular model. 

 

But - (it appears that) you are forced to do the position confirm steps every time. This will not bother those who have to do it anyway, like if you mount the ipolar externally on an OTA or temporarily on the outside of the mount. But it is a PITA if like me you have a rigidly and permanently attached ipolar cam and have done a precision calibration of the camera position from averaging or a drift alignment. I'm still checking to see if there is a way of triggering access to more advanced settings screen, but it appears there is no way of manually entering a camera position (X,Y). I'm disappointed by that as it dumbs the ipolar down to the level of Asiair and removes a clear advantage of the ipolar in being able to do and store a precise camera calibration. It also saves time as when you go out just having to do the PA is nice, rather than faffing with rotating the mount, which is even more of a bother on the newer strain wave gear. I suggest we campaign to get IOptron to put back the features of the desktop app. IOptron tech support have confirmed there is no option to clear the camera position like there is on the desktop app, but I have not received any info on whether restoring some of the desktop app features is a possibility. 

 

Anyway after position confirm it work just fine (See pic). It is nice to be able to sit in the warm on my iMac to launch and run NoMachine etc and just pop out with a phone to do the PA. Or in the field just just a phone or iPad, which used to be a USP of Asiair. 

 

The main tools running under NoMachine

 

KStars and EKOS

 

KStars is started from the "Education" menu, and once in KStars you start the EKOS (which fires up the INDI drivers) from its tools menu. My unit came with KStars 3.6.7 stable release.

 

I have now had one test run and one full imaging run. 

 

The test run revealed that KStars can crash when the USB connection to the mount drops - I had a bad cable now replace. It also revealed that the database had an odd RA and DEC for the Rosette - this was fixed on my full run by aiming for NGC 2244. 

 

I did darks, flats and dark flats with the INDI driver happily contolling my Giotto flat panel while inside. 

 

Before coming back for my full run I played with a few issues as follows:

 

Card write speeds?

 

I did wonder if my choice of 64GB card for the slot was slowing down the transfers from the camera. Writes to the internal storage were taking around the same as to an inserted Lexar class 10 card I tried first. I swapped in a SanDisk card (O Pi seem to test with those cards and recommend them) with a much higher write speed rating and it made no difference at all. It was a SandDisk Extreme Pro 64GB V30 A2 card and took the same 6-ish seconds.  I read somewhere that A1 is a bit better than A2 and one person reported a 12 MB/s write speed with an A1. So I found an A1 lying around and it made no difference at all. 

 

Camera Options: Fast Exposure, Temperature, Offset, HGC, Noise....

(You might be advised to read just a bit of this the first time - AF and Guiding below are important if you do not want to get old getting there just skip to that

 

I then rummaged through every page of the Camera settings to came across this. It does seem to do anything to fix download or write speeds but it does (appear to) speed things up rather, by letting the camera start the next exposure while KStars does whatever it needs to do with the previous one. This does make sense to me as I'd noticed that NINA exposures seem to start while NINA itself is analysing and displaying the previous image. 

 

So when you start EKOS a window appears that shows the status of the various devices. If I select my camera, here showing an AA26C TEC, there are various tabs to make your camera settings. I would have a good look through these pages as they are critical for setting your camera up correctly, and furthermore...

 

N.B. KStars 3.6.7 MIGHT FORGET YOUR CAMERA SETTINGS AND YOU NEED TO RESET THIS EVERY TIME

 

I asked about this on a KStars forum as was told this was a bug and I need an update. Or perhaps I can edit a config file for the default settings. 

 

It seems to remember my target resolution but not, at least for my choices:

 

MAIN tab - temperature

OPTION tab - Fast exposure (for lights and darks only I reckon)

CONTROL tab - Low noise and Offset (offset is buried right at the bottom of screen for the last tab, which is bizarre). 

 

Gain and HCG it seems to remember but that might be because I use the defaults for those. So here you need to be really careful as if you want your darks, flats and dark flats to all match you need these settings to be consistent and not forgotten. 

 

Fast exposure mode seems to get the camera to start exposure n+1 while processing exposure n. This is a good idea as long as your exposure time is longer than the processing time. I do not recommend this for doing flats, dark flats, or many very short exposures for the lights. But for the normal case of lights and darks at maybe 30s and above it is helpful. Obviously the % impact gets less as the length of a sub gets longer. But as a test I did four 10s exposures with it on and off and it took 58s and 82s respectively, so that the non-exposure overhead time dropped from 42s to 18s or from about 10.2s per frame to about 4.5s. So I am working with this for now. There is a bit more about it here

 

https://www.stellarmate.com/support/faq/cameras

 

and I have not yet had a chance to see if there is any impact on operational stability. 

 

Editing the Camera Configuration File

 

I have managed to store most (not all) the settings I need by manually editing the XML configuration file for my camera. At least some part of what you need is stored in the .indi directory of your home area. So try entering the commands in yellow (and make sure you know how to type a ~ 

 

imate@iMate:~/Desktop$ cd ~/.indi
imate@iMate:~/.indi$ ls
'Altair AA26CTEC_config.xml'
'Altair AA26CTEC_config.xml.default'
'Altair AA26CTEC(USB2.0)_config.xml'
'Altair AA26CTEC(USB2.0)_config.xml.default'
'CCD Simulator_config.xml'
'CCD Simulator_config.xml.default'
 GIOTTO_config.xml
 GIOTTO_config.xml.default
'iOptron CEM70_config.xml'
'iOptron CEM70_config.xml.default'
'iOptron GEM45_config.xml'
'iOptron GEM45_config.xml.default'

....

 

and the output is truncated. I then viewed the first Altair file and found XML commands for several (not all settings). For example, this block had zero and I replaced it with 64.

 

   <newNumberVector device="Altair AA26CTEC" name="CCD_OFFSET">
        <oneNumber name="OFFSET">
64
        </oneNumber>
    </newNumberVector>

 

But I have yet to find the temperature block, though there is one for temperature ramp. I won't pretend this is a perfect solution. I do not know where other bits of data are stored, or if I should just add some plausible XML blocks for what I am missing, or delete the lot and start again - that last idea stems from wondering why this particular collection of files was created - it is possible that the first run of creating a profile makes them with whatever you put in at that point, but the problem is then that subsequent changes are ignored. Another complication is that the ~/.indi area is not the only place info is stored. There is also this sql stuff: 
 

imate@iMate:~/.local/share/kstars$ cd ~/.local/share/kstars
imate@iMate:~/.local/share/kstars$ ls -al userdb.*
-rw-r--r-- 1 imate imate 135168 Jan 16 15:25 userdb.sqlite
-rw-r--r-- 1 imate imate 135168 Jan 16 15:27 userdb.sqlite.backup

 

Not sure what is in there... I might hack around with this some more. Perhaps it is easier with 3.6.8 or later. I just need to remember the temperature now, and if I forget that it is also possible to reset that from the control panel where you take pictures. 

 

AUTOFOCUS - warning - possible KSTARS user incompetence warning

 

I got a nice AF with the EKOS tool. Eventually.  But there's something odd going on, or perhaps more charitably I haven't figured out how to work it properly yet. I had the usual issues trying to find a nice step size for my SESTO motor. It defaulted to something huge and immediately went so far out of focus it could not detect stars, but having taking the step size down to 75 I started to get a nice parabola for the HFR, using automatic star detection. It labelled the minimum point (write it down) and then proclaimed that the "Solution" was some other number and went there. This "Solution" appeared to be the motor step of the left end of the parabola, with a rubbish HFR. This happened twice, so I ignored it and told the motor to go to the minimum manually. Nice sharp stars then. I have no clue why this is happening. So for the time being I can run an AF semi-manually but cannot set it to run mid sequence.  Is it a bug or is it me? Another issue is that during the AF itself it seems to be unidirectional. So it likes to go high and works it way down on the step counter, and if that happens to just make the HFR increase it does not notice that things are just getting worse and go the other way. Hocus focus in NINA copes fine. 

 

GUIDING WITH PHD2 - start it first!

 

There is a nice internal guider and I've heard good thing about what it does better than PHD2. However, having used PHD2 under various other schemes I know my mount settings for it so want to keeping using it. 

 

Be sure to select PHD2 as your external guider and not iinguider etc. The thing that held me up was not realising initially that you need to start PHD2 before you do anything with EKOS. It is NOT like NINA where NINA can boot it. PHD2 seems to need to be up and running and then EKOS can connect to it. It is then just fine and dithers, restarting image after a dither as is normal. 

 

FULL RUN OUTCOME

 

The AF glitch aside the IMate ran a medium length imaging session on the Rosette, taking 40 180s light frames with the NBZ filter on my Sharpstar 61EDPHIII. Completely stable. 

 

Is it fast enough? I think so. It is a bit clunky doing stuff like plate solving, or pulling up the fits viewer with each image. Tooltips was a bit slow, though I did notice it was faster over ethernet or now as a client of a faster home wi-fi. When imaging, especially doing DSO with FastExposure enabled, it goes as fast as any other system I have. I'm reminded of a discussion in a previous job where a colleague was showing his new Apple Watch which was much faster than the previous one. It's a watch. So there as here the core task is fast enough. For normal DSO imaging there is no problem for a sensor the size of my IMX 571 Hypercam 26C. I cannot comment on more power hungry systems of course, and robustness with a wide variety of gear. Sustained fast data transfer work projects would not be sensible. 

 

The dumbed down ipolar IS annoying though. As is not being able to update KStars directly from the usual repositories. I might go back to look at the update routines. 

 

 

 

 

 

 

 

 

 

 

 

 

Edited February 6 by William Shaw
Link to code to switch to be client of home wi-fi

[William Shaw]

I made a correction on the spec of the underlying unit. It is not an RPi3 but an Orange Pi 3 LTS which does apparently have a USB3 port as discussed here:

 

http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/orange-pi-3-LTS.html

 

However, in spite of that I have not been able to squeee out any faster performance than when using the USB2 port.  Whether this is a USB speed setting or a bottleneck elsewhere is not yet clear. 

Edited January 9 by William Shaw
better description

[Anne S]

I was wondering if the image would be able to handle dslr imaging with a Skyguider pro, with or without guiding. I've looked at other pi based solutions but only the image seems to be able to use the iPolar. I'd use platesolving to centre the target as the Skyguider can't connect to image.

Other Linux software can control the Canon dslr.