User Tools

Site Tools


power_lab_notebook

Notes on WISP power consumption


December 10th, 2008 - modulator tests


[Note: I am actually posting these notes a month later; I've been negligent about keeping this up to date – my bad. - Polly]

These are some results from using an attenuator to test the BJT and CMOS modulators.

Test #1 -attenuator in line w reader antenna, attenuator set to 0, antenna .5m from wisp, read rate in t/s, three samples on each device

old mod - 36.12/33.19/30.03
new mod - 55.62/57.23/59.86

Here is a screen grab of the old BJT modulator in action:

oldmod_atten.jpg
Blue are packets coming from the reader, yellow are response packets from the tag, and purple is Vout.

Here is a screen grab of the new CMS modulator:
newmod_atten.jpg
Again, blue are packets coming from the reader, yellow are response packets from the tag, and purple is Vout.

Test #2 - at what attenuator setting do we kills reads? -attenuator in line w reader antenna, antenna .5m from wisp

old mod - dribs and drabs on 9, reads killed entirely on 10
new mod - dribs and drabs on 9, reads killed entirely on 10

Another modulator test we ran was measuring Vout current consumption with tx clock and modulator on 50% duty cycle on P1.1, in active mode. (Data Richa collected with modulator on 100% duty cycle and lpm4 is elsewhere in this Wiki.).

prototype w/ old BJT mod: 680 uA - 700 uA
prototype w/ new CMOS mod: 684 uA - 707 uA

test #2 - lpm4 all the time, 1.1 out high

new mod 29.76 uA
old mod 6.14 uA

test #3 - am, with 1.1 out high
new mod 726 uA
old mode 681 uA

At the end of all this testing and given the sometimes contradictory results we got from the modulator tests, Dan decided to do the new design so that you could use either modulator. Once we got the finished boards back, we could just use whatever modulator gave us the best functional performance.

December 3rd, 2008 - update - "BIT_IN_ENABLE use considered harmful" - CORRECTED


Note: Argh! in my original version, I managed to (1) post some data that was incorrect, (2) use the wrong names for the types of modulators, and (3) bury the most important point deep in the text. Unfortunately, the Wiki doesn't seem to allow you to enter strikethrough characters, so I'm just going to delete the old version and rewrite this entry from scratch. If you want to see the original version, look in the “page history” section.-Polly

In the course of integrating the 3.5 MHz receive code into the Impinj tip code, I came across some interesting performance differences between the old BJT modulator and the new FET modulator, as well as the use of the BIT_IN_ENABLE pin. I ran this experiment with the antenna two meters away, talking to the two '2132 prototypes loaded with the main-read-experiments.c code in activePwrMgmt, using an Impinj reader run by Richa's and Francisco's LTKNet app. “When BIE pin used” means I disable the comparator when I get a complete Query packet, and “when BIE pin NOT used” means I leave the comparator enable pin on in that same situation.

modulator type
perf when BIE pin used (tags/sec)
perf when BIE pin NOT used (tags/sec)
old BJT mod
11
12.5
new FET mod
1.9
6


In other words, the BJT modulator beats the FET modulator by a lot when you look at a basic performance metric. Also, not using the BIE pin beats using it by a little in the case of the BJT modulator. And not using the BIE pin beats using it by a great deal in the case of the FET version of modulator.

My guess about what's going on, at least with respect to the BIE pin: we've seen the case where readers want to see n identical packets come back in time t before they will register the tag as seen. My hypothesis is that toggling the BIT_IN_ENABLE pin on the FET modulator version somehow messes up the device such that it can't always respond quickly enough to query packets from the Impinj reader. In other words, the power benefits you get from shutting off the comparator are more than outweighed by the negative impact you have on the reader-side validation algorithm. (This might not be true with other readers, of course.)

December 3rd, 2008


Dan, Alanson and Polly converged on a hw spec for the Challenge WISP. We agreed that the '2132 was the way to go. Dan is going to do some more noodling about why the fet modulator hasn't been as good to us as we think it should have been before deciding whether to stick with the cmos version. The matter of regulators is also to be decided. Polly put in a request for dual voltage supervisors. We'd like to have a 2.2v eeprom, but Dan and Alanson need to figure out how much of a power hit it would be, and if there is some reaosnable workaround for those who don't need it (e.g. jumpering). Lastly, we'd like an RTC, even if we don't have code for it, because it seems likely that someone will need it.

The tentative schedule is for board design next week, and heading out to PCA for stuffing the week of 12/29.

November 29, 2008


Aim: Measure the Vout current on the new and old modulator
Equipment: MSP430F2132 Microcontroller (Mock-up board)
Method 1: No pins on microcontroller are set to high. Microcontroller is in LPM4. Power supply is connected in series to the multimeter which is measuring current draw on Vout. Reader is not running.
Method 2: Only the modulator output pin on microcontroller is set to high. Microcontroller is in LPM4. Power supply is connected in series to the multimeter which is measuring current draw on Vout. Reader is not running.
Results:

Pin set to high
Power Supply Output Voltage (V)
Old Modulator Vout Current (uA)
New Modulator Vout Current (uA)
None
2.0
4.3
2.6
None
3.0
7.2
5.5
Transmit
2.0
473
32.8
Transmit
3.0
470
30.0


November 26, 2008


Whoohoo, reads are working! This is code from C:\Documents and Settings\powledge\Desktop\2008-11-24 - Active Pwr Mgt on the lab machine, but using main-read-experiments.cpp instead of main.cpp. It returns 1 word of read data, and it's a counter that gets incremented for every read command received, so you can tell when you're missing data. The hardware is the '2132 prototype with the new modulator. Here's the results:

cold start test - what is the maximum distance you can start up a reader and get read data, however slowly? With my C++ app, it was 5'6“. With Richa's and Francisco's LLRP app, it was an inch or two more.

Next step was to figure out at what distance you can get 5Hz of data. At five feet I was getting about 5.2 tags/sec. If you look at the counter data in the “Result” column, you'll see that about 60% of the samples got through.
5hzread.jpg
Next up, figure out at what distance you can get 10Hz of data. This was about 4 feet 6 inches. Thirty-one samples were sent out by the WISP, of which 25 made it back to the app, for around 80% performance.

10hzread.jpg

Lastly, I looked for a distance at which I could get 20Hz of data; this turned out to be 3 feet 8 inches. We recorded 25 of 27 samples, for performance around 92%.

20hzread.jpg
The main-read-experiments.cpp code is derived from some pretty old code. So the next step for me is to see if I can transfer this goodness into the tip code.

November 26, 2008 - Dan notes


Metric conversions:

  • Reads work great to 1.3 meters, then crash quickly. By 1.7 meters no reads. Scope trace would be helpful here.
  • Query/Ack works out past 3 meters.

No significant benefit from new modulator, even for Reads - this is unexpected!

  • Should take a Vout current measurement with modulator ON and MCU in LPM4 as sanity check.

Lingering Questions:

  • Given that the 2132 and 2272/4 consume about the same current, why does performance vary hugely between them?
  • Why do reads crash at around 1.5 meters?
  • It seems we are ready to fab a board - who is doing the layout?


November 26, 2008 - Polly reply to Dan notes


Here are some scope traces. This is a failed read command on the '2132 with the new mod:

failed_read_command.jpg
For comparison, here is the same firmware on the same device with the antenna moved closer, and reads working:

good_read_command.jpg
Comments (dan):
Comparing dv/dt (the current consumption between the two graphs (assuming the wisp power consumption didn't change), this basically shows that measuring dv or dv/dt with the scope is not reliable without more investigation. (graph 1 = 510 uA, graph 2 = 386 uA)
Also interesting to see both graphs show some signs of brownout towards the end, with the failing plot actually failing mid-read response (the bits stop prematurely).
Possible solutions: raise SV, increase cap size, use a timer-based build-up-power scheme. Any other ideas?


November 25, 2008 - meta


Sometimes I (Polly) feel like I can get lost in the weeds, and lose sight of the big picture. So I stepped back and asked myself what the goals were. I came up with this:

  • We want a device that runs an query/ack/sensor sampling application fast enough at a reasonable distance to operate the Saturn demo. “Fast enough” seems to be at least 10 tag reads/sec. “Reasonable distance” seems to be a minimum of two meters.
  • We would like to have a device that can handle read commands at some reasonable distance. As before, “reasonable distance” is probably a minimum of two meters. I really haven't heard any definitions of what “fast enough” is for this application.


The good news is that my tests with the '2132 prototype say we've already got bullet item #1. I mean, we still need to do end to end testing, but there are no showstoppers lurking here.

Bullet item #2 is the open question. So I started to focus on that with my testing. Using the '2132 with the new mod, I found that (1) the Active Power Management code was replying to the read commands, (2) there was now plenty of power to do this on the '2132, but that (3) the read commands weren't being accepted by the reader side. In other words, the power constraints that were killing us on the '2274 are gone on the '2132. Now it's a matter of fixing the firmware. Based on this, I claim that we ought to commit to the '2132.

So, now it's time for your meta. Are these the right goals? Do you think the '2132 is the right choice? Hit that “edit this page” button.

November 25, 2008 - postscript


Polly put the '2132 prototypes through the test harness. Using the 2008-11-24 - Active Pwr Mgt code, we got some of the best range we've seen yet – 10 to 11 feet, and a steady 10Hz at 6 feet (enough to run the Saturn demo). However, I wasn't able to see much of a difference between the prototype with the old modulator and the prototype with the new modulator. Here's my data:

cold start test - what is the max distance you can start up a reader and get a tag, however slowly?

'2132 with old mod
'2132 with new mod
11 feet 9 inches
10 feet 8 inches


read rate tests

distance (ft)
'2132 with old mod (tags/sec)
2132 with new mod (tags/sec)
10 feet 6 inches
2.8
0
6 feet
11.6
9.8


Dan had this to say about the test results:

The read rate differences don't seem very substantial. We might notice the difference, however, if we start trying to do reads (which would benefit from reduced average current).

The cold start difference could be differences between the AFE's. If not the AFE, is the new mod wisp unsuccessfully sending Query responses? Some scope information on how the wisp is failing could suggest some next steps here.

I was talking to Richa last night about trying to get that last meter out of wisp. It has plenty of voltage, but has trouble getting packets across successfully. I have a couple ideas involving using the watchdog to monitor our packet rate, asking questions such as:
- has the demod been on for a long time to no avavil? if so, try turning if off for x ms and then try again
- are we running out of voltage, if so what can we do?
- if we want to do reads, how can we get some extra voltage to hold through to the end of the read?


November 25, 2008


The proposed approaches and test results are flying around fast and furious. I'll try to summarize them, and if I mischaracterize something, well, the “edit this page” button is at the top and just waiting to be pressed. :^)

  • “the Alanson tests”. Dan and Polly ran versions of these, and they didn't turn out at all the way we thought they would. Given the datasheet claims and Polly's results of 11/24, you would expect the Alanson tests to show better power management on the '2132 relative to the '2272/'2274. But the Alanson tests showed no benefit for moving from the '2274 to the '2132. We are flummoxed. Maybe these tests aren't good models for what we're trying to measure?
  • Dan and Richa found that the receive clocks in firmware for the '2274 and the red WISP ('2012) are running at 5.7 MHz. We should be able to successfully receive with the clocks running closer to 3.5 MHz. Of course, the lower the clock speed, the lower the amount of power consumed.
  • Dan did a CMOS version of the modulator, and putting it together with the '2132 saw an anecdotal improvement in range. The improvement needs to be measured more rigorously, though. They did a quick try at the same thing with a '2274, but didn't see any parallel improvement.


Polly will try repeat Dan's results and collect some hard data about read rate and range today. Next, we should be looking at slowing the receive clock down.

BTW, Dan will probably be back in the lab on Monday. Polly will be in the lab Wednesday, and occasionally on-line over the weekend (Verizon gods willing).

November 24, 2008


OK, now I've got a screen grab of Query-ACK on the red WISP with Vout, instead of Vreg.(Dan, this was a great catch!)

This is a '2012 mcu, and a 1.8V voltage supervisor running different firmware (\\Slfiles02\shareddata\richa\For_Polly\01 - Mother of all codes - WISP G2 - Works with all readers) against the Impinj reader driven by its web app. Blue is the incoming bits from the reader, yellow is the WISP replies, and purple is Vout. So what you're seeing here in between the cursors is a Query reply start, an ACK, and an ACK reply.

query-ack-red-wisp-real-vout.jpg


Just to summarize what we've got:

hardware
firmware
Vout drop (mV)
red WISP ('2012-based)
01 - Mother of all codes - WISP G2 - Works with all readers
260.8
purple WISP ('2274-based)
test2132.c (compiled for 2274)
233.1
mauve WISP ('2132-based)
test2132.c (compiled for 2132)
183.5


While this shows us heading in the right direction with the '2132, there are plenty of confounding factors (e.g. firmware) that make this table a little, uh, Fiji to McIntosh. Alanson sent around some mail on November 23rd:


Instead of measuring Query-Ack performance to evaluate hardware I suggest using a software independent method.
Earlier I compared the Red vs Purple WISP by watching the RC discharge on the storage cap.
· LPM4
· LPM4 with Demod_Enabled
· LPM4 with Demod_Enabled and RFID activity
· Active mode at transmit frequency and using the ALU in a while loop, multiplying by 3
If we run those same four tests for the new WISP then we can compare apples to apples. If the new hardware performance is the same or better then the Red WISP (which the data sheet suggest) we can infer the difference is a coding issue.


Remember that in Alanson's earlier experiments (WISP Power Hunt.docWISP Power Hunt.doc

), he showed that the purple WISP did a little worse than the red WISP in pure LPM4, a little better in both the LPM4/demodulator tests, and significantly worse in active mode. So if we repeat these tests with Dan's prototype and show that we're at some rough parity (or maybe better) with the red WISP, then I think Alanson is right and we ought to be able to do as much with the mauve WISP as we can with the red WISP.

November 23, 2008


Dan's suspicion was right: when I got the layout files in front of me and traced out where the red wire went on the red WISP, I could see that the wire landed on Vreg, not Vout. This means the beautiful flat line reported in the October 31 postscript entry isn't realistic goal. Unfortunately, I had problems getting the real Vout for the red WISP today. I'll work on this more tomorrow, and post a revised screen grab when I get the data.

November 22, 2008


Dan put together a prototype with the '2132 in place of the '2274, to see if switching MCUs could improve matters. Executive summary: it did, but not as much as we would have liked.

Here is the '2132 query-ack sequence. Again, blue is incoming, yellow is outgoing bits, and purple is Vout. From the beginning of the query reply to the end of the ACK reply, we chew up 183 mV. Dan thinks this prototype is basically equivalent to the #4 WISP that Alanson pried various parts off ot.

query-ack-2132.jpg
For comparison, I recompiled this same firmware for the ''2274 and did the same test:

query-ack-2274.jpg



It clocks in at 233 mV, so we get about a 25% improvement when we switch MCUs.

But what about that nice flat line we see with the red WISP (Oct. 31 postscript)? Why can't we get that? Dan doesn't believe the red WISP screen grab at all, and swears we must've been probing Vreg instead of Vout. I have to take off, but I will come back tomorrow and redo that test.

**November 20, 2008**


Alanson spent some time digging into the power consumption issues. He has concluded that the mcu itself is the culprit, and that we should switch to a mcu part number with a lower draw in active mode. He proposes the MSP430F2132, which has 8K of flash. Our largest application is around 3100d bytes, so it will fit easily. We hope to have a hw prototype together in the next few days.

Alanson's report is here: WISP Power Hunt.docWISP Power Hunt.doc



I looked into firmware porting, and found one issue relating to TimerA. The '2274 has one of these, but the '2132 has two. The '2132 header file has some #defines to make this less painful, but the preprocessor doesn't know how to translate the #defines if they're embedded in a larger string, as they are in the asm-intensive sections of the code. I was thinking that we might want to keep the '2274 around as a potential data logger platform (it has 32K of flash), so I was disinclined to just switch over to the '2132. So I added some #defines of my own to maintain source-code compatibility between the two part numbers. I haven't put any of this into cvs yet, because it's all unproven for now. But in theory it works great! :^)

One note: compiling for the '2132 required upgrading my copy of IAR kickstart to 4.11B and a FET firmware upgrade.

November 11, 2008


Josh suggested adding a 22 uF cap to the purple WISP and seeing how it affected power consumption. Again. this is the #4 WISP with a 2.0 voltage supervisor and various external components like SRAM removed. Blue are incoming bits from the reader, yellow are outgoing bits to the reader, purple is Vout, and green is a debug pin indicating an ACK response. Measuring from the beginning of the Query response to the end of the ACK response, we use up 40 mV.


query-ack-purple-wisp-added-cap.jpg


As a baseline, here is the same WISP running the same firmware without the additional cap. It uses up about 100 mV. We're moving in the right direction here.

query-ack-purple-wispno-added-cap.jpg



Now we try the same experiment with a 220uF cap. Now this is what we want to see:

query-ack-purple-wisp-220uf-cap.jpg

November 3, 2008

We did some more experiments today.

For the first experiment, Alanson removed extraneous components that we didn't need – e.g., external SRAM. Repeating the “how much power gets consumed from the start of a Query response to the end of an ACK response?” experiment from October 31st on this modified hardware, we found that it reduced power consumption from 150 mV to 110 mV:

query-ack-reduced-purple.jpg

Here, purple is Vout, blue is incoming bits, yellow is outgoing bits, and green is a debug pin. In a read command, that would knock the consumption down from 352 mV to about 258mV. Nice, but not a magic bullet solution.

The goal of the next experiment was to find out what percentage of this power hungry behavior is due to the hardware and what percentage was due to the firmware. For this I ported the firmware that behaves so well on the red WISP (\\Slfiles02\shareddata\richa\For_Polly\01 - Mother of all codes - WISP G2 - Works with all readers) to the purple WISP, and then measured power consumption from the beginning of a query response to the end of an ack response. (This revised firmware is on the lab machine, on powledge's desktop, in the folder purple_mother.)

To make the port work, I remapped the voltage supervisor pin assignment; changed the send and receive clocks; and rearranged the sequence of instructions at the beginning so the device could boot up. And since I was running this on the same #4 WISP that I used for the previous experiment, it was running on a stripped-down WISP hw version 4.0.

query-ack-red-code-on-purple-wisp.jpg

Using the ported red WISP firmware resulted in a 10 mV savings over a 4.12 ms period, but still gave us a significant disadvantage over using red WISP firmware on a red WISP. It appears the device itself is 91% of the problem, and the firmware is 9% of the problem.

Update: Since the experiments I've been running have been very close to the antenna, Alanson asked me to rerun the previous experiment with a little bit of distance. I moved the antenna out to 2 feet 6 inches, where I was still getting some packets back but saw a real dropoff in ACK packets sent. Again, this is ported red WISP code on a slimmed down purple WISP with an Impinj reader. In this setup, I saw a 150 mV decline from the start of a query response to the end of a ACK response:

query-ack-red-code-on-purple-2ft-6in.jpg
Again, blue are incoming bits, yellow are outgoing bits, purple is Vout (and Richa borrowed the green probe. :^).

October 31, 2008 postscript

In today's meeting, Alanson suggested that it would be nice to have power consumption data on reads on the red WISP as a baseline. This turned out to be a spectacularly good idea. NOV. 23/24 addendum: the purple line is actually measuring VREG, not VOUT. This is NOT a valid test!! See the Nov. 23/24th entries for more information about this.

To be clear: this is different hardware (a smaller microcontroller, and a 1.8V voltage supervisor) running different firmware (\\Slfiles02\shareddata\richa\For_Polly\01 - Mother of all codes - WISP G2 - Works with all readers) against a different RFID reader (ThingMagic) using Richa's GUI app. Same antenna, though. :^) Thanks to Richa for getting me set up with the ThingMagic stuff.

Anyways, on to the scope grab. As elsewhere, blue is the incoming bits from the reader, yellow is the WISP replies, green is a debug pin that marks the sending of the ACK reply, and purple is Vout. So what you're seeing here in between the cursors is a Query, a Query reply, an ACK, and ACK reply, a Request_RN, and Request_Rn reply, and finally a Read command and its reply.

read-cmd-red-wisp.jpg
Look at this thing — Vout is basically a flat line! (The antenna is just under two feet away, the same distance I used with the purple WISP tests.)

Unfortunately, there's no shortage of confounding variables to consider when you're trying to figure out why this works so well. It could be the smaller micro. It could be the reader, or it could be the reader app, or it could be a combination of these.

On Alanson's suggestion, I ran the Thingmagic reader and Richa's app against the purple WISP. I didn't expect the full command to work out of the box (and was not disappointed :^), but I thought I could tell some interesting things from looking at Vout:

read-cmd-purple-wisp-thingmagic-reader.jpg
(Note: Richa needed a probe for her work, so I lent her the blue one from the lab scope. This is why the incoming bits are missing from the scope grab.) You can see that Vout varies. How much? I measured from the beginning of the Query reply to the end of the Ack reply, a period of 4.12 ms where the device is in active mode nearly all the time:

read-cmd-purple-thingmagic-2.jpg


It loses 150 mV over that 4.12 ms time period. If a full read command with the Imping reader takes 9.68 ms (12.13 ms, less that block of time between the Request-RN reply and the incoming Read command, when the device is in LPM4) and if we pretended that the relationship was completely linear, that would come in at a 352 mV loss due to the device itself. Slightly less than 30 mV of this is due to the Impinj reader, or the application driving the Impinj reader.

October 31, 2008

I've been reworking the code, and decided to run some more read command experiments.

Here is a 1-word read command using the Mach1 app on an Impinj v3.0 reader. This time, I'm starting the clock when the WISP gets the first bit of the Query command from the reader. The previous experiment started from the first bit the WISP sent in response to the Query command. As you'd expect, it's slightly longer:

read_cmd-length.jpg
Blue are bits that the reader sent, yellow are bits that the WISP is sending back, green goes high when the ACK response is sent, and purple is Vout.

Now let's measure how much power this command sequence uses. Again, I'm measuring from the first bit the reader sends me in the sequence:

read-cmd-power-use.jpg
This comes in at 380 mV, which is slightly lower than the hand-wave-y number I used in the October 29th tests. This scope grab is of the same sample above, so all the colors mean the same thing as before.

OK, what if there's something terribly inefficient I'm doing in the chain of commands that's draining power, and making these numbers worse than they need to be? I captured another sequence that used debug pins to tell me when I'm in LPM4 and when I'm active. When purple is high, I'm in LPM4, and when it's low, I'm in AM:

read-cmd-purple-shows-lpm4.jpg
This shows me that I'm sleeping when I should be; it's hard to see how this sequence of commands could be made more efficient from a power viewpoint. So I claim that handling a read command on a hw4.0 WISP is going to cost you 380 mV, period. If the microcontroller runs at 1.7-1.8v, this points to something like a 2.1-2.2v voltage supervisor.

Just to be clear, this should in no way be interpreted as a claim that there is no more efficiency work to be done on the firmware side. I think there's plenty more code-flogging left to do to increase the hit rate and range in firmware. On this point I feel … firm. :^)

These tests were run on the #4 WISP with twinned 2.0V voltage supervisors. The WISP fw version used is derived from hw40A_D51.c, “almost.cpp.”


October 29, 2008

Ever wonder how long it takes to perform a query-ack sequence? From sending out the query response to sending out the ack response, it takes a little over 4 ms. Green indicates incoming bits, yellow indicates outgoing bits, and blue is Vout.


query-ack-normal-2.0vs-color.jpg
Query-Ack sequence



How about a read command, where it's reading just a single word? Using our Impinj Mach1 application, it takes a little over 12 ms from the first query response to the read command response. In this scope grab, blue is getting toggled when the read response is sent.

1w-read-mach1-app-2.0vc-color.jpg
If you took query-ack firmware and changed it so that it appending outgoing bits to the query, and kept this up so that you were going from query-resp to the end of the outgoing extra ack bits for 9.3 ms, what would you do to Vout? You'd chew up about 370 mV. (In this scope grab, blue is Vout again.)

query-ack-how-long-to-crash-2.0vs-color-horiz.jpg
How much power?



So that straight-lines out for a typical one-word read sequence to consume somewhere around 480 mV. Now, admittedly, this is experiment is going to skew badly. For example, there's about block of the time where you've sent out the request-rn response but aren't getting any incoming bits. So let's adjust for that and say a read sequence is really 9.68 ms long. Now this straightlines out to 393 mV. Now, this is still flawed, because it assumes the cost of sending out bits is that same as the cost of receiving bits, and because it ignores the short LPM4 sessions in between incoming bits as the packet is being assembled. But this should give you feel for what kinds of demands a read command puts on a WISP.

This data was collected on WISP #4 with a twinned 2.0V voltage supervisor, running version 1.1 of Hw40A_D51.c. The reader is the Impinj reader, running version 3.0 of their firmware. The query-ack data was collected with the web app, and the read data was collected with the Mach1 ReadTag application.

power_lab_notebook.txt · Last modified: 2018/07/11 08:25 (external edit)