1) It have to be without power adapter so I need a "battery", which is
the cheapest way to feed the raspberry? I googled for it but I see
battery hats for 3-4 € and UPS hats for 30-40 € but I don't undestand
the differences between them.
2) I would like to use Visual Studio Code to develop the software side.
For the power consumes is it better to install a full OS (Raspberry Pi
OS with desktop) or a limited one (Raspberry Pi OS Lite) and develop in different ways?
The display has a power consume of 48mW during refresh and I would like
to refresh it once at hour (maybe 30 minutes), obviously it will be
connected by wi-fi.
Once a week/month/year I can take it from the wall, charge it an the put
it again on the wall.
I have some questions to people more expert than me:
1) It have to be without power adapter so I need a "battery", which is
the cheapest way to feed the raspberry? I googled for it but I see
battery hats for 3-4 € and UPS hats for 30-40 € but I don't undestand
the differences between them.
2) I would like to use Visual Studio Code to develop the software side.
For the power consumes is it better to install a full OS (Raspberry Pi
OS with desktop) or a limited one (Raspberry Pi OS Lite) and develop in >different ways?
On Thu, 16 Dec 2021 15:00:37 +0100, Giangi72 <invalid@invalid.net>
declaimed the following:
The display has a power consume of 48mW during refresh and I would like
to refresh it once at hour (maybe 30 minutes), obviously it will be
connected by wi-fi.
What voltage/amperage? That may have a limitation on what type of power source you can use.
Once a week/month/year I can take it from the wall, charge it an the put
it again on the wall.
I have some questions to people more expert than me:
1) It have to be without power adapter so I need a "battery", which is
the cheapest way to feed the raspberry? I googled for it but I see
battery hats for 3-4 € and UPS hats for 30-40 € but I don't undestand
the differences between them.
UPS is "Uninterruptible Power Supply" -- a system that uses wall power most of the time, but can switch to battery backup when the wall power
fails -- and can do this in a way that the attached device does not notice
a power glitch. If it is a good one, when the wall power comes back up, it will recharge the battery. It may also (via monitoring software and GPIO or such) signal to the R-Pi if both wall power has been lost, AND the battery
is running down -- so the R-Pi can perform a clean shutdown.
Obviously needs a power adapter for normal operation.
In contrast, a plain battery is just that... a battery that can run down. Linux systems do NOT like having the power pulled -- it can lose unwritten data (at best) requiring a journal rebuild of the file system on next start-up, up to corrupting the file system beyond recovery.
2) I would like to use Visual Studio Code to develop the software side.
For the power consumes is it better to install a full OS (Raspberry Pi
OS with desktop) or a limited one (Raspberry Pi OS Lite) and develop in
different ways?
I'm tempted to suggest you develop on one device using a full desktop if you require any graphical editor/development environment, and then
install the application on a device without a desktop system. Your application sounds like it could run using the smallest WiFi enabled R-Pi, but for development (especially if using C/C++ or other compiled language) might be better on a larger/more powerful R-Pi model.
Does a library already exist for the display, or do you have to create that too?
Actually, have you even done a search to see if this has been done already? The first page of a search on Google found two implementations
(the first having way too many reviews/references on the page <G>)
https://www.tomshardware.com/news/raspberry-pi-e-ink-google-candar https://github.com/speedyg0nz/MagInkCal
https://hackaday.com/2019/02/11/get-organized-with-this-raspberry-pi-e-ink-calendar/
My problem is now mainly on power and power duration: which cheap hat use to power the raspberry.
And then my later question to reduce the power consume
3) Is there any way to suspend the raspberry after refresh and restart it again
before next refresh to save power?
During refresh, I read on datasheet
Typical operating current 6.6 mA
Perfect, but are there any battery hats (cheaper) that can tell to
raspberry how many remaning charge they have?
e.g.
https://thepihut.com/products/li-ion-battery-hat-for-raspberry-pi
but I found the same, in the past, a 3-4€
This could be a good idea, or develop on a full OS sd card and the swap
to a liter SD card.
But in terms of power consume: what happens if I use a full desktop OS
and the switch off the desktop environvent?
https://www.waveshare.com/wiki/7.5inch_e-Paper_HAT_(B)
I know this project, but it is in pyton, some informations are very
useful but not the whole project
My problem is now mainly on power and power duration: which cheap hat
use to power the raspberry.
And then my later question to reduce the power consume
3) Is there any way to suspend the raspberry after refresh and restart
it again before next refresh to save power?
Giangi72 wrote:
My problem is now mainly on power and power duration: which cheap hat use to
power the raspberry.
And then my later question to reduce the power consume
3) Is there any way to suspend the raspberry after refresh and restart it again
before next refresh to save power?
Maybe use an ESP32 instead of an RPi?
Giangi72 wrote:
My problem is now mainly on power and power duration: which cheap hat
use to power the raspberry.
And then my later question to reduce the power consume
3) Is there any way to suspend the raspberry after refresh and restart
it again before next refresh to save power?
Maybe use an ESP32 instead of an RPi?
I don't know ESP32, what I see is that it is an arduino-like board.
From what I saw I'm not sure it is able to support complex software as google calendar as mentioned in another message, but I'm not an expert
Some addtional informations here https://stackoverflow.com/questions/19766912/how-do-i-authorise-an-app-web-or-installed-without-user-intervention/19766913#19766913
What are the main advantages to use ESP32 instead of Raspberry pi?
On Thu, 16 Dec 2021 17:58:30 +0100, Giangi72 <invalid@invalid.net>
declaimed the following:
During refresh, I read on datasheet
Typical operating current 6.6 mA
Taking your previous statement of 48mW and this 6.6mA, that yields a 7.3V power source (W = V * A). Raspberry-Pi's provide 5V and 3.3V (and
GPIOs can be killed if fed more than 3.3V; the 5V is from the input power supply and primarily provided to USB ports)
Perfect, but are there any battery hats (cheaper) that can tell to
raspberry how many remaning charge they have?
e.g.
https://thepihut.com/products/li-ion-battery-hat-for-raspberry-pi
but I found the same, in the past, a 3-4€
Did you look at the documentation for that unit?
I know this project, but it is in pyton, some informations are very
useful but not the whole project
So what is wrong with Python -- it IS the language the R-PI foundation targeted for users <G>
For an hourly/half-hourly (or whatever rate you want to refresh) you don't need the speed from using a compiled language. And the easiest way to set up that timing would be to have the application merely do one refresh
and exit -- and invoke it using a crontab entry specifying how often to
run.
3) Is there any way to suspend the raspberry after refresh and restart
it again before next refresh to save power?
WiFi is likely the biggest power drain you have on an R-Pi.
Andy Burns <usenet@andyburns.uk> wrote:
Giangi72 wrote:
My problem is now mainly on power and power duration: which cheap hat use to
power the raspberry.
And then my later question to reduce the power consume
3) Is there any way to suspend the raspberry after refresh and restart it again
before next refresh to save power?
Maybe use an ESP32 instead of an RPi?
That was my first thought. Although it depends how complicated the Google Calendar API is, and whether it's something the ESP software can handle. If it's basic JSON or something it'll probably be fine, but if it needs lots of stateful stuff (OAuth etc) that could be harder. Something like CalDav
looks quite complicated.
But maybe you could run that part on a server/a RPi and have the ESP
poll it with simpler requests?
I quite like the M5Stacks as neatly packaged ESP32 boards, with batteries
and displays: https://shop.m5stack.com/products/m5paper-esp32-development-kit-960x540-4-7-eink-display-235-ppi?variant=37595977908396
https://shop.m5stack.com/products/m5stack-esp32-core-ink-development-kit1-54-elnk-display?variant=37404426174636
What are the main advantages to use ESP32 instead of Raspberry pi?
This means there is no way to power raspberry by battery and let it last
for at least a week?
In article <j23attFm984U1@mid.individual.net>, invalid@invalid.net
says...
This means there is no way to power raspberry by battery and let it
last for at least a week?
I think your options are...
1. Use a Very Big battery. AFAIR, a PiZeroW draws around 250 mA on
average, when idling, so something around 40 Ah at 5V. Say 20 Ah at 12V, after you've included the 12V->5V voltage converter. It'll be something
like a car battery in size, and correspondingly expensive.
2. Add some extra circuitry to completely power off the RPi between
refreshes (making sure you wait until the RPi has shut down cleanly
before cutting the power). I think you'd have to home-brew this
circuitry.
3. Use a different processor, e.g. Arduino, ESP32, RP2040. I don't have
any personal experience, but I think these all support a low power deep- sleep mode from which you can wake on a timer.
Giangi72 wrote:
What are the main advantages to use ESP32 instead of Raspberry pi?
putting it to deep sleep between updates, and boards with available LiPo battery management.
Andy Burns ha scritto:
Giangi72 wrote:
What are the main advantages to use ESP32 instead of Raspberry pi?
putting it to deep sleep between updates, and boards with available LiPo
battery management.
Could you please give me more informations about the battery management.
Only links is enough
The RP2040, aka PICO, may be what the OP wants. Its cheap, low power, can
be made to sleep for a user-definable time, and is intended to be
programmed in C/C++ or PICO-assembler. It has no OS - just a set of
support code, including a C standard library. You link your application
code with C library etc and the hardware-specific support libraries to
get a binary blob. Load that into the PICO, connect power and it runs.
All the documentation is on the PICO section of the RaspberryPi
Foundation website so, if this sounds interesting, go and read the docs.
The process of developing code for it looks similar to the way you'd
program a Parallax STAMP or a PICAXE chip except that both of those are programmed using their own flavours of compiled integer BASIC while the
PICO can be programmed in C/C++.
What are the main advantages to use ESP32 instead of Raspberry pi?
putting it to deep sleep between updates, and boards with available
LiPo battery management.
Could you please give me more informations about the battery management.
Only links is enough
e.g. <https://unexpectedmaker.com/tinys2>
500mA Max charging current."
1) What does it means? If I have a 700mA or 1000mA battery? Sorry for this newbie question.
2) I don't understand how to charge the battery once it is connected to the board. Using usb port or detaching it and charging it externally?
The RP2040 and the RPi Pico don't have networking. You can connect it via a wire to a USB port, but that's not what the OP wants.
It seems the Arduino people have an 'Nano RP2040 Connect' which has a u-blox NINA WiFi module on it... that has an ESP32 inside.
So you might as well just use an ESP32 to begin with.
Giangi72 wrote:
500mA Max charging current."
1) What does it means? If I have a 700mA or 1000mA battery? Sorry for
this newbie question.
I presume you mean 700mAh or 1000mAh capacity, rather than 500mA
charging current, just mean it'll take between 90 minutes and 2 hours to charge
2) I don't understand how to charge the battery once it is connected
to the board. Using usb port or detaching it and charging it externally?
whenever USB power is supplied, the board will charge the battery.
What are the main advantages to use ESP32 instead of Raspberry pi?
1. Use a Very Big battery. AFAIR, a PiZeroW draws around 250 mA on
average, when idling, so something around 40 Ah at 5V. Say 20 Ah at 12V, >after you've included the 12V->5V voltage converter. It'll be something
like a car battery in size, and correspondingly expensive.
3. Use a different processor, e.g. Arduino, ESP32, RP2040. I don't have
any personal experience, but I think these all support a low power deep- >sleep mode from which you can wake on a timer.
Charging Li-Ion batteries is not simple, advanced charging circuits
include temperature sensors to detect when the charge has peaked and avoid overheating the battery.
[CUT]
This means there is no way to power raspberry by battery and let it last
for at least a week?
Giangi72 <invalid@invalid.net> wrote:
[CUT]
This means there is no way to power raspberry by battery and let it last
for at least a week?
It's possible...it's just a matter of figuring out how big a battery pack >would do that. Someone else theorized that a pack built of 14500 Li-ion >cells (two in series, presumably, through a buck converter to get 5V) might >run a Raspberry Pi 3B+ for five hours. 18650s are more common and larger; >for sake of argument, let's say you get 3x the runtime (2400 mAh) from an >18650 as you'd get from a 14500. If two 18650s would run the aforementioned >RPi 3B+ for 15 hours, 24 18650s in a 2S12P configuration would provide 7.5 >days of runtime.
Whether a pack made of two dozen 18650s would be too large for your >application is a question only you can answer. :)
I wouldn't advise it! Once you start stacking up large numbers of
batteries all sorts of load balancing issues become apparent - both for charge and discharge.
The benefit of of these time sources is that it doesn't matter if your calendar does get killed by a storm or power cut: when power comes back
the system can re-boot and re-establish an accurate time in a few minutes
at most. also, it will still work if the power cut took out your section
of the internet.
Finding out the time is not the problem, getting the calendar updates
is. The dilemma is that something that can handle the complexity of
talking to the Google servers is probably not low power enough to run
from a battery in a wall frame for a week/month/year. Which is what
makes me think a two-box solution is the way forward.
That requires an internet connection. You can't display the
appointments in their calendar without fetching it from the internet - you could only have a generic day/date calendar which is not what they're asking for.
Theo wrote:
That requires an internet connection. You can't display the
appointments in their calendar without fetching it from the internet -
you could only have a generic day/date calendar which is not what
they're asking for.
That's not true. All my calendars are local to my phone and not synced
Theo wrote:
That requires an internet connection. You can't display the
appointments in their calendar without fetching it from the internet - you could only have a generic day/date calendar which is not what they're asking
for.
That's not true. All my calendars are local to my phone and not synced
to anything not fully under my control. I regularly save backups over my
LAN at home and could import that to any other local calendar.
In the present case you do have a point though, unless the OP is
satisfied with having his appointments on the wall at home and nowhere
else. But that too does not need the internet. Syncing between the (presumably) phone and the wall box over the LAN when at home would
suffice.
Like I said, the OP's calendar lives on Google Calendar. You can't fetch that without internet, because that calendar lives in the cloud. You can sync to something locally (a server/phone/another Pi), and then the wall frame fetches from there, which is the two-box solution I suggested. If
you want a one-box solution you need internet on your one box, there's no getting around that.
On Mon, 20 Dec 2021 23:05:36 GMT
scott@alfter.diespammersdie.us wrote:
Giangi72 <invalid@invalid.net> wrote:
[CUT]
This means there is no way to power raspberry by battery and let it last >>> for at least a week?
It's possible...it's just a matter of figuring out how big a battery pack
would do that. Someone else theorized that a pack built of 14500 Li-ion
cells (two in series, presumably, through a buck converter to get 5V) might >> run a Raspberry Pi 3B+ for five hours. 18650s are more common and larger; >> for sake of argument, let's say you get 3x the runtime (2400 mAh) from an
18650 as you'd get from a 14500. If two 18650s would run the aforementioned >> RPi 3B+ for 15 hours, 24 18650s in a 2S12P configuration would provide 7.5 >> days of runtime.
Whether a pack made of two dozen 18650s would be too large for your
application is a question only you can answer. :)
I wouldn't advise it! Once you start stacking up large numbers of batteries all
sorts of load balancing issues become apparent - both for charge and discharge.
just pick a battery that has the capacity you need and is happy to be trickle charged at slightly more than the Pis power draw.
Hasn't stopped renewable energy though, but then they never bothered to analyse it, they just built it for profit. irrespective of whether it
worked or not.
The Natural Philosopher wrote:
just pick a battery that has the capacity you need and is happy to be
trickle charged at slightly more than the Pis power draw.
Once you reach the point where the battery is too large to fit within
the frame on the wall, you either have to re-think whether a dangling
power cable is acceptable, or use something other than a Pi ...
Like I said, the OP's calendar lives on Google Calendar.
On Wed, 22 Dec 2021 12:21:39 +0000, The Natural Philosopher wrote:
Hasn't stopped renewable energy though, but then they never bothered toThe only really crazy item on the table right now is so-called "Blue Hydrogen": the energetics of making it mean that burning coal is less environmentally damaging than making and using the 'Blue hydrogen'.
analyse it, they just built it for profit. irrespective of whether it
worked or not.
I beg to differ. Everything on the table right now is crazy.
I've spent many years analysing it, and the only thing that will
actually work, other than a 97% drop in population and a return to the
sort oft technology the Greens would understand. Presumably horses whose methane emanations would be forgotten in their sheer organicity... is
nuclear power of some sort.
Its abundant, uranium is ubiquitous, cheap and easily stockpiled, and
comes already stored. The reactors are well understood known technology,
and it transpires that radiation isn't nearly as dangerous as we had
been led to believe, and we could easily achieve adequate safety at much lower cost.
That doesn't sort out the use of fossil fuels as chemical feedstocks of course, and as the only appropriate energy density energy source to fly transatlantic airliners,
On Wed, 22 Dec 2021 13:18:14 +0000, The Natural Philosopher wrote:
I beg to differ. Everything on the table right now is crazy.You're certainly right about population. That seems to be such a bad
I've spent many years analysing it, and the only thing that will
actually work, other than a 97% drop in population and a return to the
sort oft technology the Greens would understand. Presumably horses whose
methane emanations would be forgotten in their sheer organicity... is
nuclear power of some sort.
thing to say that its not even whispered about by anybody. Yet, any
attempt to prevent global warming is doomed to failure without reductions
in both the humam population and in individual (net) resource consumption.
Its abundant, uranium is ubiquitous, cheap and easily stockpiled, andMaybe it can be used, presumably in small factory-produced, reactors
comes already stored. The reactors are well understood known technology,
and it transpires that radiation isn't nearly as dangerous as we had
been led to believe, and we could easily achieve adequate safety at much
lower cost.
similar to those used in submarines, but studies I've seen point out that
in terms of global warming, nukes still produce around 30% of the CO2
from conventional thermal generation once mining and refining the stuff
is taken into account:
Storm van Leeuwen & Smith - http://www.stormsmith.nl/
This also fails to ignore the problem of dealing with fanatics who think nuking someone or something would Be A Good Idea.
I'n not against nuclear, PROVIDED THAT the problems of disposing of the radioactive waste from fuel preparation and the radioactive debris from decommissioning old plant can be sorted out. To date the solutions have mostly been to pile the junk in a corner and hope nobody notices it.
That doesn't sort out the use of fossil fuels as chemical feedstocks ofTrue enough, do we really need so many transatlantic airliners? Also, I'm seeing talk of running ships on Ammonia rather then heavy oil:
course, and as the only appropriate energy density energy source to fly
transatlantic airliners,
NH3 + O2 => N2 + H2O + energy
Is ammonia's energy content high enough to run an airliner? Gaseous hydrogen's isn't and nor is liquid hydrogen's once to take density/volume/ container mass into account.
Theo wrote:
Like I said, the OP's calendar lives on Google Calendar.
Perhaps I misunderstood, or at least understood differently. For you a
Google calendar is a calendar maintained for you by Google in their
cloud. For me it's the calendar app in my phone and provided by Google.
And that phone app typically duplicates appointments in Google's
"cloud" to make them available to other devices
using the Rugbk (UK) time signal
I've used Jonathon Buzzard's receiver and Rugby in the past
Theo wrote:
Like I said, the OP's calendar lives on Google Calendar.
Perhaps I misunderstood, or at least understood differently. For you a
Google calendar is a calendar maintained for you by Google in their
cloud. For me it's the calendar app in my phone and provided by Google.
"The energy density of ammonia is 22.5 MJ/kg at HHV, which is about half
of that for typical hydrocarbon fuels but higher than metal hydrides (Zamfirescu and Dincer, 2008; Züttel et al., 2010). The raw energy
density of liquid ammonia is 11.5 MJ/L, which is higher than the 8.491
MJ/L for liquid hydrogen and the 4.5 MJ/L for compressed H2 at 690 bar
and 15°C1 . Ammonia is a good energy vector for on-board hydrogen
storage (Green, 1982; Klerke et al., 2008; Lan et al., 2012). However,
safety is regarded as the major drawback of using ammonia as the fuel. Ammonia is toxic but it is detectable by humans in concentrations of
just 1 ppm (Reich et al., 2001). Anhydrous ammonia is lighter than air
then tends to disperse in the atmosphere. NH3 would be as safe as the
use of gasoline as a transportation fuel (Olson and Holbrook, 2007). The ammonia released from an ammonia tank during a car accident may cause potential safety problem but this can be solved through the application
of metal amines with low ammonia partial pressure (Klerke et al., 2008).
Compared to hydrogen, ammonia is easier to be transported. It is much
more energy efficient and much lower cost to produce, store, and deliver hydrogen as NH3 than as compressed and/or cryogenic hydrogen (Figure 1) (Olson and Holbrook, 2007). The infrastructure for ammonia already
exists while for hydrogen, new fueling stations have to be built, which
is a big investment (Lan et al., 2012)."
https://www.frontiersin.org/articles/10.3389/fenrg.2014.00035/full
The problem is that nitrogen don't oxidise and release energy, it
oxidises and releases nastyShit.™
You really want to reduce CO2 and water and make synthetic hydrocarbon. Trouble is there is bugger all CO2 in the atmosphere.
So whereas it might be OK in a fuel cell in a car to go with ammonia, it
isnt really going to make a nice pollution free plane ride.
But what may in fact be the answer is bloody damned fast nuclear ships
The larger the ship the less drag at a given speed per unit weight, and
ships - containers and tankers - are conventionally operated to find a
local minimum to the cost equation. Too fast and you burn more fuel per
tonne mile, too slow and your cost of capital per tonne mile increases.
If your fuel cost is peanuts but your cost of capital is high, and
that's the case for a nukey ship, your accountant will tell you to push
it to the maximum speed it can handle, and your engineers will start
talking about lifting it out of the water on hydrofoils, or building an ekranoplane as well.
If one wants to say, do southampton to new york in a day, before taking
a high speed electric train, that's probably 120-150mph Well within ekranoplane range, but not sure about hydrofoils. its above the world
record for a hovercraft, but not by much.
A displacement nuclear ship should do it in 2-3 days nuclear subs have
broken 50mph as well
Anyway,. my point is that climate change and renewable energy are all
red herrings, there is no shortage of nuclear fuel and all the problems
in using it for land and sea based installations are eminently soluble.
What there is is a r9ising shortage of affordable fossil fuels.
All the problems with nuclear arise with portable power off grid. And
basic chemical feedstocks. I think the feedstock chemistry is soluble,
but portable off grid power is a real bugger.
You really want carbon based fuels, but without fossil sources, carbon
is in very short supply, and the only means of getting it out of the air
is really using biofuel of some sort - algae and the like. Possible
nuclear illuminated photosynthesis tanks to remove it from the air
might work, but we are already right on the lower limits of CO2 in the
air which allows plants to work efficiently - we really would need CO2
up around 800ppm to get that to be efficient.
On Wed, 22 Dec 2021 15:25:12 +0000, The Natural Philosopher wrote:
"The energy density of ammonia is 22.5 MJ/kg at HHV, which is about half
of that for typical hydrocarbon fuels but higher than metal hydrides
(Zamfirescu and Dincer, 2008; Züttel et al., 2010). The raw energy
density of liquid ammonia is 11.5 MJ/L, which is higher than the 8.491
MJ/L for liquid hydrogen and the 4.5 MJ/L for compressed H2 at 690 bar
and 15°C1 . Ammonia is a good energy vector for on-board hydrogen
storage (Green, 1982; Klerke et al., 2008; Lan et al., 2012). However,
safety is regarded as the major drawback of using ammonia as the fuel.
Ammonia is toxic but it is detectable by humans in concentrations of
just 1 ppm (Reich et al., 2001). Anhydrous ammonia is lighter than air
then tends to disperse in the atmosphere. NH3 would be as safe as the
use of gasoline as a transportation fuel (Olson and Holbrook, 2007). The
ammonia released from an ammonia tank during a car accident may cause
potential safety problem but this can be solved through the application
of metal amines with low ammonia partial pressure (Klerke et al., 2008).
Compared to hydrogen, ammonia is easier to be transported. It is much
more energy efficient and much lower cost to produce, store, and deliver
hydrogen as NH3 than as compressed and/or cryogenic hydrogen (Figure 1)
(Olson and Holbrook, 2007). The infrastructure for ammonia already
exists while for hydrogen, new fueling stations have to be built, which
is a big investment (Lan et al., 2012)."
https://www.frontiersin.org/articles/10.3389/fenrg.2014.00035/full
The problem is that nitrogen don't oxidise and release energy, it
oxidises and releases nastyShit.™
You really want to reduce CO2 and water and make synthetic hydrocarbon.
Trouble is there is bugger all CO2 in the atmosphere.
So whereas it might be OK in a fuel cell in a car to go with ammonia, it
isnt really going to make a nice pollution free plane ride.
But what may in fact be the answer is bloody damned fast nuclear ships
The larger the ship the less drag at a given speed per unit weight, and
ships - containers and tankers - are conventionally operated to find a
local minimum to the cost equation. Too fast and you burn more fuel per
tonne mile, too slow and your cost of capital per tonne mile increases.
If your fuel cost is peanuts but your cost of capital is high, and
that's the case for a nukey ship, your accountant will tell you to push
it to the maximum speed it can handle, and your engineers will start
talking about lifting it out of the water on hydrofoils, or building an
ekranoplane as well.
If one wants to say, do southampton to new york in a day, before taking
a high speed electric train, that's probably 120-150mph Well within
ekranoplane range, but not sure about hydrofoils. its above the world
record for a hovercraft, but not by much.
A displacement nuclear ship should do it in 2-3 days nuclear subs have
broken 50mph as well
Anyway,. my point is that climate change and renewable energy are all
red herrings, there is no shortage of nuclear fuel and all the problems
in using it for land and sea based installations are eminently soluble.
What there is is a r9ising shortage of affordable fossil fuels.
All the problems with nuclear arise with portable power off grid. And
basic chemical feedstocks. I think the feedstock chemistry is soluble,
but portable off grid power is a real bugger.
You really want carbon based fuels, but without fossil sources, carbon
is in very short supply, and the only means of getting it out of the air
is really using biofuel of some sort - algae and the like. Possible
nuclear illuminated photosynthesis tanks to remove it from the air
might work, but we are already right on the lower limits of CO2 in the
air which allows plants to work efficiently - we really would need CO2
up around 800ppm to get that to be efficient.
Thanks for the preceeding analysis of ammonia as a general purpose
transport fuel.
I'd not previously heard anything about it, pro or con, until a piece on Radio 4 mentioned it as a likely minimally polluting fuel for container ships,
so it seemed logical to consider if ot would also work for aircraft: the answer seems to be 'yes'.
Theo wrote:
Like I said, the OP's calendar lives on Google Calendar.
Perhaps I misunderstood, or at least understood differently. For you a
Google calendar is a calendar maintained for you by Google in their
cloud. For me it's the calendar app in my phone and provided by Google.
| Sysop: | deepend |
|---|---|
| Location: | Calgary, Alberta |
| Users: | 262 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 33:42:30 |
| Calls: | 1,880 |
| Calls today: | 1 |
| Files: | 4,273 |
| D/L today: |
27 files (14,110K bytes) |
| Messages: | 403,317 |