Ice tea or IoT -- what do you prefer?

When I ordered the TTGO T-BEAM, I liked that it combines LoRa and GPS and it even supports a 18650 battery (18650 cells with internal protection circuit are somewhat longer, but still fit -- although very tight) including a good charging chip to charge the Li-Ion cell -- not LiFePO -- via USB (USB can also be used to power the device without using the battery holder). The ublox NEO-6M GPS chip has a dedicated backup (super)capacitor (looks like a coin cell battery) to buffer the GPS chips' RTC and almanach, but probably only for a few minutes.

Just when the delivery arrived, I found video #182 from Andreas Spiess, reporting that older TTGO designs had some design flaws: the 868-915 MHz versions have passive RF components (coils and capacitors to tune the frequency) that are not specific enough for the 868 MHz that we use here in Europe (some even fixed that) and the LoRa antenna could be better (all the videos by Andreas Spiess can only be recommended, including the LoRa videos). I was then happy to see that in newer designs, including the T-TBEAM, the WiFi antenna is placed better and in fact, the T-TBEAM even has a connector for an external WiFi antenna (but would need some minor soldering); also the LoRa and GPS part is now shielded by a metal cage. I was relieved to find the more recent video #224 measuring the T-BEAM and other newer boards, judging the newer designs to be OK.

I already expected that a better GPS antenna might be needed (and the tiny original one is only fixed with some adhesive tape that does not hold very well).

In summary, the T-BEAM seems not to be that bad (even the passive component that are too generic for 868 MHz turn out to be OK), but many reports indicate that the power consumption is rather high (that whole thread is anyway a worthwhile reading). 10 mA seem to be the minimum possible even during deep sleep. Concerning the power consumption, there seems to be an issue with deep-sleep. There is also a video on what is possible with ESP32 and deep sleep. Update: Meanwhile a student did as part of his M.Sc. thesis power measurements with the TTGO Lora32 (i.e not the T-BEAM) and the lack of going to deep sleep is confirmed there as well.

Some people complained that they got only 900 m instead of kilometers of range. The comments for video #224 mention that an older library had a flaw concerning the transmit power which did lead in that video to a low transmission power; according to the comments, this has at least been fixed now in the LoRa library by Sandeep Mistry that can be found in the Arduino Library Manager. Update: Again in our M.Sc. thesis, we achieved 15.5 km range.

A display can also be connected, but to reduce power consumption, it might be better to make it removable by using a female header.

Andreas Spiess recommends in his videos WeMos D1 ESP8266 and a Hope RFM95W LoRa module for which even a PCB is available (recommending as well WeMos D1 as ESP2866 board) -- it however needs SMD soldering. Nexus by Ideetron has elsewhere been mentioned as low power solution, but has only a small user base and thus lacks information -- and GPS can anyway be expected to be the big power consumer.
Concerning the LoRaWAN libraries, MCCI seems to be the only one that is actively maintained and communication with The Things Network needs to save some state information (for joining via OTAA) which MCCI stores in RAM that is not buffered in deep-sleep of ESPs. So for using OTAA, MCUs that do buffer the RAM (i.e. newer ATMEL MCU like in newer Arduino) would be preferable, e.g. Atmega 1284p together with a watchdog for waking up periodically has extremely low power consumption (0.5 μA in deep sleep) but lacks GPS. Other low power designs provide even triple GNSS and acceleration-detection watchdog. In addition to the ublox GNSS chips, there are some approaches that claim to reach lower power consumption by off-loading GNSS solver processing via LoRa to some external clouds server infrastructure or doing extreme A-GPS data compression for LoRa transmission from a cloud.

The really cool thing is that even satellites serve as LoRa repeaters (if there is a clear line of sight, LoRa has a theoretical range of 1300 kilometers, thus easily reaching low earth orbit satellites). By this, sensors that have no LoRa connection to a station on the Earth can still reach a LoRa repeater in the sky and forward their messages back to Earth. (But you need an amateur radio license for the used 70 cm frequency band: 435 MHz / 436 MHz up- and downlink.)

I also got two TTGO Lora32 v1.6.1 that have LoRa, a card reader, and a tiny display on the back, but not GPS. On one of them, the WiFi antenna was already loose when unpacking (see the 3D sheet metal in the photo below). Need to check how easy it is to solder it back again (or whether rather a hot air rework station is needed) or use it as opportunity to add an SMA/UFL connector? (There is also an UFL antenna connector, but since it as close to the LoRa SMA antenna connector, I guess the UFL connector is as well for LoRa -- after desoldering some 0 Ohm SMD resistor and creating a soldering bring/reusing that 0 Ohm SMD resistor.)
Even though TTGO Lora32 comes with a cable to connect a battery, TTGO Lora32 version v1.6 had a fire issue where the battery explodes. I checked the schematics: My v1.6.1 has this issue fixed and the TTGO T-BEAM uses anyway a different charging IC that is claimed to be pretty good.

Also, double check the pinout: some complain that the pinout provided by LilyGO can be wrong.

Depending on the applications, I might use LoRa for device-to-device commnication, or LoRaWAN via The ThingsNetwork that has a coverage in Reykjavík, but fair use limits, e.g. 10 messages to the device per day, which could be avoided by setting-up my private LoRaWAN using ChirpStack.

Talking about lora (a popular name for parrots as the Spanish word for parrot is loro): did I mentioned already that the Computer Science department has moved and already a new visitor...?

As the DVB-T sender has been moved here within Reykjavík, I had to adjust my indoor antenna which is simply built by turning a coax-antenna cable into a half-wave dipole antenna (essentially, a variant of a sleeve antenna) : the outer insulation of the coax cable was removed so that the part with the inner wire has a lambda/4 length and the left-over shield was peeled and turned inside out over the insulation so that it also has lambda/4 length (in sum: lambda/2). The aluminum foil that was part of the shielding was removed and finally, the inner insulation removed so that the inner wire remains totally uncovered. Take care that remainders of the shield do not touch the inner wire.

For the details, including the calculations, see: http://www.vdr-wiki.de/wiki/index.php/DVB-T_Antennen (in German, but the calculations work in any language -- note that they use a correction factor of 0.95 for the length of the shield and 0.97 * lambda/4 for the length of the inner wire -- but, well, the antenna needs to cover some frequency range, so these corrections probably matter not that much).

More info on the senders in Iceland can be found at https://vodafone.is/sjonvarp/sjonvarpsthjonusta/thjonustusvaedi/ (see map at the bottom). The sender operated by Vodafone on Úlfarsfell broadcasts on three UHF channels with 8 MHz bandwidth:

• Channel 26 (514 MHz center frequency): RÚV HD (DVB-T2), RÚV 2 HD, BBC Brit, DR1, Food Network, Hringbraut, N4, National Geographic, Rás 1, Rás 2, Rondo (the latter are not TV, but radio)
• Channel 27 (522 MHz center frequency): RÚV (DVB-T only), Stöð 2, Stöð 2 Bíó, Stöð 2 Fjölskylda, Stöð 2 Sport, Stöð 2 Sport 2, Rás 1, Rás 2, Bylgjan, Fm957 , Léttbylgjan, Xið
• Channel 28 (530 MHz center frequency): Stöð 2 Golf, Stöð 2 Sport 3, Stöð 2 Sport 4, Animal Planet, Discovery.

Using 522 MHz, lambda/4 is 14.36 cm which I used for the above DIY antenna.

With the older sender where I had an unblocked line of sight, the reception was yielding almost 100% signal strength and signal quality, but with the new location of the sender on Mt. Úlfarsfell, my reception got really bad (there is a hill and high buildings in the line of sight) and signal strength is even fluctuating, which might be explained by the weather, e.g. rain can be expected to weaken the signal strength.

In addition to the above programmes, my TV receives a far stronger DVB-T signal on on channel 41 (634 MHz -- which means the calculated lambda/4 does not fit perfectly, still the received signal strength is close to 100%) which must be another sender than the one from Vodafone (it anyway broadcasts missionary programmes only).

The EOSC-Nordic project has a knowledge hub that contains knowledge on using the European Open Science Cloud, e.g. services for storing and finding research data or accessing cross-border scientific computing (in particular with a Nordic focus): https://www.eosc-nordic.eu/knowledge-hub/.

I (and many others) always had problems making JUnit (as added by Eclipse automatically when creating JUnit test cases) work with modular projects, i.e. projects that use module-info.java files to define dependencies. Finally, I found solutions:

• Let the new project wizard not create the module-info.java file -- deleting it afterwards might not be enough as Eclipse did already some modification the the module path settings (OK, trivial) or
• Choose Java ≤8 in settings (i.e. module-info.java ignored -- again: trivial) or
• Apply quick-fixes: in the class containing your JUnit test cases, hover over the org.junit.jupiter.api import and select the quick-fix: “Add ‘requires […]’ to module-info.java”. Then in module-info.java: hover with mouse over the squiggle line (the important point is: clicking on the light bulb does not give any quick-fix, so you need to hover) and do: “Move classpath entry ‘JUnit5’ to modulepath”. This should fix it! or
• Create an Eclipse project with extra src folder (e.g. src-test or use the Maven default structure) that has (via “Allow output folders for source folders”) its own output folder (e.g. bin-test or use the Maven default structure) and that has “Contains test sources” toggled to “Yes” (in project properties - Java Build Path -Source). The test src folder should then have a more grey-ish icon. Either do this with the New project wizard, or afterwards using project properties. As a result, JUnit is then not part of the modular project anymore. (Has also the advantage that test code is better separated.)

The Computer Science department has moved to the new Gróska building (between Askja building and the DeCode Genetics building -- probably, most people know it, because there is a gym on the ground floor and CCP is located there). The official visiting address is: Bjargargata 1, 102 Reykjavik. You can find us also on OpenStreetMap.

(I still need to find out which address needs to be used for paper mail to end up in the department's post inbox.)

The Computer Science department is on the 3rd floor -- the same floor where CCP is located, however, we are at the southern-most wing of the building -- see the purple lines in the photo below. Inside the building, take either the stairway A or B -- stairway B is closest to us. Inside the building, you will also find signs: Tölvunarfræði HÍ:

The floor plan of the Computer Science department is below. The two most popular meeting rooms are: the big teaching room Ada is GR-321, Alan Turing is honored by room Alan in GR-310, and meeting room Charles has number GR-326.

I am located in room 306. The phone numbers are now routed via MS Teams that I am not going to install on my Linux system: rather call me on my provided mobile phone number.

In the beginning, we were lacking furniture for visitors: I had to build our own chairs out of cardbox, e.g.: https://www.wikihow.com/Build-a-Cardboard-Stool or https://www.hometalk.com/diy/decorate/rooms/diy-cardboard-stool-looks-like-wood-31556361?expand_all_questions=1

In the meantime, we got visitor chairs and some other visitor:

In addition to a bicycle storage room for employees, there are also EV chargers, however an RFID card from Bílahleðslan is needed (if you need the RFID key urgently, rather fetch it from them, because the mail delivery takes two to three weeks) -- they use the IT infrastructure from Everon and some of the involved registration emails are prone to be deleted by spam filters.

Update: it seems that e1 has now taken over the billing for the charging stations.

Shiraz Memon successfully defended his PhD thesis in Computer Science on Federated Access to Collaborative Compute and Data Infrastructures. The thesis covers how researchers can perform eScience by discovering services (such as accessing data and processing data) on remote research and e-infrastructures and authenticate (such as logging in order to use the service) and how authorization can be done (i.e. deciding which services are allowed to be used).

The thesis was streamed, Wed, 30. June 2021 starting from 09:30 (UTC), and the recording is available via: https://livestream.com/hi/doktorsvornshmedshirazmemon

This PhD is an example of the collaboration between the Faculty of Industrial Engineering, Mechanical Engineering and Computer Science and Jülich Supercomputing Centre (JSC).

Members of the PhD commitee were Morris Riedel, Helmut Neukirchen, and Matthias Book, opponents were David Wallom and Shukor Abd Razak. The head of faculty, Rúnar Unnþórsson, was steering the defense.

While I intended to use a Raspberry Pi 4 as a small server, I also ordered from China a small system (BEBEPC, comparable to the Qotom mini PCs. While Qotom mini PCs are slightly better documented, they typically have less powerful CPUs: even though they have Core i3 CPUs, these are so old that a more recent Celeron CPU is faster) based on a Intel J4105 CPU (= TDP of 10 W, 4 cores, 1.5 GHz base frequency, 2.5 GHz burst frequency) which has over the Raspi the advantage of native SATA ports (one standard SATA connector with 5 V power supply and one mSATA connector carrying 3.3 V power supply -- I ordered an mSATA to SATA adapter and a 5 V SATA power splitter cable to be able to have a RAID system of two SATA SSDs -- mSATA SSDs are only available in smaller sizes. But note that the SATA ports are only 3 Gbit/s, i.e. 300 MB/s, which means that a 500 MB/s SSD is already overkill). However, the biggest advantage is that it is (obviously) able to run Intel-only code, e.g. in particular Virtual Machine images or containers only available for Intel, e.g., using Proxmox VE.

Both systems come with 8 GB LPDDR4 RAM, but for the J4905, even 16 GB are possible (see below).

Both systems can be passively cooled: for the Raspy, I used a cooling case from (Update 2024: the now defunct) https://www.coolingcases.com/ -- it cools well, but the metal affects the range of the onboard Wifi (not that relevant for a server). The J4105 came as well with a case that allows passive cooling -- while it is still tiny for a PC, it has approx. 4 times the volume of the Raspi.

As you can see in the above photos, squeezing to SATA SSDs (for RAID) was a challenge and I had to bend the connector cables very tightly (which might not be healthy for the connectors, cables, PCBs). Therefore, I had considered removing the 2.5" case from the SATA SSDs and using only the bare PCBs. But as you can see in the photos below, there were pads glued to the SSD controller chip and I am not sure whether these are thermal pads and the metal case is needed as heat sink. Hence, I decided to keep using the case. (On the other hand, the second pad is only marginally covering the two NAND chips and the NAND chips on the second side of the PCBs are not padded at all -- so maybe, the pads are just mechanical to prevent rattling.)

SSD case open (HDD for comparison)

SSD PCB with pads (are these thermal pads?)

The J4105 system has for sure more compute power than the Raspi's ARM CPU, so the remaining question is the power consumption. Hence, I did some tests and measurements using a cheap power meter that claims to have a 2% precision. Both systems were connected at FullHD via HDMI to a monitor.

Intel J4105 measurements

As at the beginning, I did not had installed Linux yet, it was running Windows 10 and idle refers to having only the built-in task manager running in foreground (to display clock frequency) and all the background services that Windows 10 has by default. CPU load was generated using a batch file containing an endless loop.

The J4105 clocks down to 0.78 GHz when idle and the power consumption of the whole system (with one mSATA and one SATA SSD) is then 3.8 W.

With 1 core being busy, it still clocks up to 2.4 GHz and consumes 7.2 W.

With 2 cores being busy, it still clocks up to 2.4 GHz and consumes 10.3 W.

With 3 cores being busy, it clocks up to 2.35 GHz and consumes between 11.8 W and 12.1 W.

With 4 cores being busy, it clocks up to 2.19 GHz and consumes between 11.4 W and 12.0 W. (So it seems the reduced clock saves power).

I did run it with 4 cores being busy for an hour, and the measurements did not change, e.g. no thermal throttling seems to have occurred (nor did the case get hot, so a really good passive cooling -- or the contact between CPU and case is bad, but then thermal throttling could have been expected).

Raspberry Pi 4 measurements

I had OSMC with KODI running, but nothing else, i.e. the KODI UI being idle, but all the background services running. The latest firmware as of 4. June 2021 was used, storage was SDHC card only. CPU load was generated using the stress command.

The Raspberry Pi 4 consumed idle 3.8 W to 4.0 W.

With 1 core being busy, it consumes 4.5 W.

With 2 cores being busy, it consumes 5.0 W.

With 3 cores being busy, it consumes between 5.4 W and 5.5 W.

With 4 cores being busy, it consumes 6.0 W.

Temperature with the cooling case from https://www.coolingcases.com/ was approx. 52° C (so it prevented thermal throttling that would start at 80° C). Surprisingly, even in idle mode, the temperature was 40-42° (the tiny case does feel much warmer than the bigger case of the Intel system -- so, it seems: size matters).

Conclusions

In summary, the idle power consumption of both systems is comparable and while the busy consumption is lower with Raspberry Pi 4, it is of course less powerful than the J4105 system. For the J4105, I never observed the full 2.5 GHz burst clock rate (but 2.4 GHz). Even though the CPU TDP is 10 W, the whole system consumed up to 12.1 W (e.g. the RAM, the two SSDs, WiFi, HDMI output, external power supply, etc. probably also to add their share -- during boot, I even saw 14.8 W).

Note that others suggest 2.7 W idle for the Raspi 4 (but seems to require switching off a lot of I/O, e.g., HDMI etc. -- which I did not do, nor did I minimise background processes) or even as low as 2.1 W. On the other hand, many other report that they neither (with either a fan or a heatsink) get the system cooler than 42° in idle, so getting the Raspy warmer than the touch of your hand seems to be normal, but the J4105 system with the bigger case was considerably cooler.

It seems that the J4105 is a good 24/7 home server system, i.e. more powerful than the Raspi when needed, but still not consuming more power when idle. (A German c't article confirms this for a thin client that is also J4105-based.)

The ultimate (at time of writing) passively cooled server with ECC ram would be ASRock Industrial iBOX-V2000M or iBOX-V2000V -- but these are not available for private users. But any ASRock motherboard in general, together with AMD Pro CPUs should support ECC.

Some documentation on the BEBEPC system

RAM: 16 GB DIMMs supported

An even more powerful system based on J4125 (= J4105 with higher clock) suggests that with Dual-Rank-Modules even 16 GB per RAM module are possible, i.e. with two banks, even 32 GB of RAM. Power consumption of that J412-based system has also been measured which is higher (best explained by the fact that it is faster, i.e. cannot clock down as much: 2000-2700 MHz vs. 1500-2500 MHz).
I therefore ordered a 16 GB DIMM: I can confirm that this works. However, my system has just 1 RAM socket, so 16 GB is the maximum.

Auto power on

It seems that to make the system automatically power-on after a power outage, a jumper needs to be set at PWRON1 at the pins marked PWR_SW1.

Independent from that, the system does not start after having been powered off -- not even after the power button has been pressed: in this case, the RTC/CMOS battery needs to be removed and inserted again.

BIOS settings

F11 or DEL to enter the AMI BIOS.

F2 to select boot drive.

MAC address can be found via Advanced.

Change OS to Linux via Chipset-South Bridge.

Change SATA Device Type to SSD via Chipset-South Cluster Configuration (not sure whether Mechanical Presence Switch setting matters and needs to be disabled).
Not sure about DITO (the time a given port must be idle before HW may enter DevSleep autonomously): might help if SSD gets hot/consumes to much energy.

Chipset-Miscellaneous Configuration: Power Button Debounce Mode disable to make the power button to come back from standby mode.

Security-Secure Boot: Disable if booting Linux causes problems.

Security-Quiet Boot: Disable to see some BIOS messages at boot.

Boot: Change order of boot devices.

US keyboard

On German/Icelandic keyboards, the pipe symbol is left of the enter key if US keyboard layout is assumed.

Update 2023: Intel N100, N200 and N300/N305 Alder Lake N CPUs

The Intel N100, N200 and N300/N305 CPUs are some sort of successor of the J4105 CPU. N100 and N200 have both 4 cores and N200 can clock higher and has a better GPU than N100. The numbering is a mess (e.g. N95 is faster than N100), as a rule of thumb: those CPUs ending with the digit 5 are allowed to get hotter (i.e. higher TDP), i.e. they can probably sustain longer using all cores at highest speed. But I do not know what the reason for the different TPD is (are the different TDPs the same silicon die, but base on whether they can handle higher temperature they get binned into the digit 5 CPUs?). N300/N305 has 8 cores and also marketed as "Core i3". While they support only one DIMM (i.e. single channel being slower than two memory channels), they support DDR5 RAM which is anyway 50% faster.

If the BIOS supports it, these system even allow ECC, see my post on the iKOOLCORE R2 for more details on the ECC. Even if the BIOS does not support enabling IBECC, there are claims that using the AMISCE tool from AMI, you can set this from command line (and then reboot -- just take care that you can clear the CMOS/NVRAM or have some rescue mode), e.g. on Linux, this is the SCELNX_64 / scelnx tool, but maybe the uefisettings tool works as well?

That Chinese Intel i3-N305 fanless mini PCs look also good, but you never know what backdoors are int the BIOS. The Protectli systems have coreboot, but are more expensive and have outdated hardware, i.e. none of these new processors. Starlabs Byte has an N200 with coreboot, but DDR4 RAM only. The official maximum RAM is 16 GB according to Intel, but there are systems offered with 32 GB:

• TerraMaster F4-424 Pro NAS with N300 and 32 GB RAM. (While Terramaster is Chinese, it might be interesting to see when the non-Chinese QNAP and Synology offer Alder Lake N-based systems, but in contrast to TerraMaster, installing your own Linux, e.g. TrueNas Scale, is not well supported.)
• CWWK Magic Computer with various CPUs and RAM configuration and it has even a PCIe socket
• iKoolCore R2 it has a fan but is super tiny. For details, including getting ECC to run on Linux, see my blog post on the iKOOLCORE R2.
• ODROID H4 from Hardkernel which is South-Korean, so no China BIOS -- hence the ODROID H4 sounds a very good buy and also the support provided by Hardkernel seems to be good. But it does not come with a decent case. If you sacrifice the NVM SSD, you can use the NVM port (which is in fact just PCIe) to add 4 further 2.5 Gb Ethernet ports, making it a great router, however you then either need to use the slow eMMC or the SATA ports for storage.

Note that most of the above come with Intel Ethernet Intel i226 chips that have a good driver support in Linux and BSD, however there are claims that these chips crash after a couple of hours and the only way to prevent this is to switch of PCIe power saving (ASPM) -- on the other hand, you find people reporting their n100 systems with i226 running rock-solid.

In general, these new CPUs are slightly faster than, e.g., a 8 core C3758 Xeon-like Atom CPU that is three years older, but supports more RAM and even ECC. But these new CPUs are more I/O limited (in terms of PCI lanes) in comparison to that 8 core C3758 Xeon-like Atom CPU that has 25 W but can still be passively cooled.

A test of an Intel N200-based fanless mini from Asus with DDR4 RAM mentions that N200 with DDR5 RAM is faster. Idle power consumption is claimed to be 5-6 W and 22 W under full load.

Others show for a N305 system idling 15-16 W which is significantly more. (But the N305 has 15 W TDP vs. 7 W for the N300 -- otherwise, both CPUs are exactly the same; I guess, the N300 will simple start to throttle when stressing all cores. But the N305 can also be restricted via BIOS to a lower TDP.) There, you find also a performance comparison with a Raspberry Pi 4 and Pi 5: N100 is twice as fast as a Pi 5 and four times faster than a Pi 4, and N305 is almost twice as fast as an N100.

Studying Software Engineering is important because Software is the future and future is starting right now. And someone needs to create all this software that is shaping our future.

Software Engineering is more than just programming, it rather looks at big picture, namely the whole life of the software: from the start where you need to talk to customers to find out what software they actually need over to the actual programming, user interface and user experience, quality assurance and this is all guided by project management where you need to make people work together.

Software Engineering covers so many different aspects that students need to come from all kinds of different backgrounds:
female and male, those who are good at math, those who are good at communicating with other people, those who are picky about details, those who are creative. Essentially everyone!

When you start studying Software Engineering, you do not need to be able to program: you will learn that in our courses. But you need to be able to talk to other people and at the same time do not fear thinking like an engineer, such as doing math and applying systematic processes!

The nice thing about developing software is that only your imagination is the limit: you can create everything just by turning your mind into code and then it runs and you can see it immediately working. This is so rewarding!

Studying Software Engineering at the University of Iceland is very practical: you do not only learn the theory, but also apply it in the courses. For example, in our Bachelors program, there is a Software Engineering project that spans a whole full year.

Those who graduate from here, will find easily a job at a good salary and can work in fact in all kinds of different fields: be it banking, insurance, health, industry, administration, tourism, gaming, even arts:
simply everywhere, Software is nowadays needed!

Further information

If you want more information on our Software Engineering programmes:

Bachelor (B.Sc.)

Software Engineering (Hugbúnaðarverkfræði)

Master (M.Sc.)

Software Engineering (Hugbúnaðarverkfræði) Update from 2024: -- we added recently the specialisation in Cybersecurity

Ph.D.

And of course, you can also do a PhD in any of these programmes. Before you apply, contact a professor: either by a personal visit or -- if you are located abroad -- by writing an old school paper letter (professors get hundreds of email with PhD applications where it is obvious that the same email was written to many professors and thus, these email are considered as spam -- but a paper mail makes an impress)!

If you rather want to study Computer Science or Computational Engineering

While the above text was intended to convince you studying Software Engineering, you might still be interested in our other programmes:

Bachelor (B.Sc.)

Computer Science (Tölvunarfræði) -- we have a specialisation in Data Science (i.e. AI) and added 2023 the specialisation in Cybersecurity.

Master (M.Sc.)

Computer Science (Tölvunarfræði)

Computational Engineering (Reikniverkfræði)

Salary

For a salary (typically distinguished: base salary and overall salary with the typical amount of paid overtime – overtime is not always paid, though) outlook, you can find surveys on Icelandic salaries at unions (stéttarfélag), e.g.:

• VR (starfsheiti “Tölvunuarfræðingur”)

and at professional associations, e.g.:

• Software Engineers: Verkfræðingafélag Íslands (VFÍ)
• Computer Scientists: Félag Tölvunarfræðinga (FT) (only for members)
• Félag Hugbúnaðarprófara á Íslandi (Hugpró) (only for members)

In addition there is also on interesting blog post on the different companies and their salaries (Netherlands -- Iceland might be different).

But be aware that salary alone is not everything, but work-life balance counts or that big and old companies are typically less chaotic (i.e. have well defined procedures) which may give you as a beginner more guidance, but you might at the same time fell more restricted.

The Horizon 2020 Future and Emerging Technologies programme: Dynamical Exascale Entry Platform - Extreme Scale Technologies (DEEP-EST) project has finished its work and was praised for its results in the final review of the project's outcome.

We still have to harvest our results by writing publications on the results, but you can find a video already here:

All our travel emissions have been offset. As it is not clear whether funding regulations allow to offset emissions due to supercomputer energy consumption, these were not compensated. However, one of the research topics of the DEEP-EST project was energy efficiency and we achieved a lot by using specialised (=more efficient) accelerator hardware.

The European Centre of Excellence RAISE (Research on AI- and Simulation-Based Engineering at Exascale) is holding an online seminar on using the Interaction Room Software Engineering approach for HPC Systems Engineering.

This approach has been described in this publication:
Matthias Book, Morris Riedel, Helmut Neukirchen, Markus Götz.
Facilitating Collaboration in High Performance Computing Projects with an Interaction Room.
The 4th ACM SIGPLAN International Workshop on Software Engineering for Parallel Systems (SEPS 2017). Co-located with SPLASH 2017 as an ACM SIGPLAN-approved workshop.
October 23, 2017, Vancouver, Canada. DOI: 10.1145/3141865.3142467, ACM Digital Library 2017.
Download

The recording of the online seminar can now be found on the CoE RAISE YouTube channel: