diff --git a/docs/data/overview.md b/docs/data/overview.md
index 5a4f48f..fc30786 100644
--- a/docs/data/overview.md
+++ b/docs/data/overview.md
@@ -5,7 +5,7 @@ In order to assess your Loop's performance and more specifically your settings,
 ## Problem with traditional methods
 As a person with diabetes, you’re probably carrying around a lot of different devices that are holding a lot of different data; a blood glucose meter for your finger sticks, a pump for insulin delivery, a continuous glucose monitor for real-time glucose measurements, phone app for tracking meals, etc. When you go to your endocrinology office, you probably start the process by dropping many of those devices at the front desk to be individually downloaded and then having to pack all of them away 20 minutes later.
 
-Then your clinic staff has the less-than-efficient process of trying to overlay all those different devices into some sort of cohesive strategy for how your diabetes may need some tweaks. Because of Loop use, a clinic currently has to look at separate reports from Medtronic pump, Contour Next Link BG meter, Dexcom CGM/Clarity, and our iPhone Health app, as a typical example. There are also a couple of issues with Loop when using this separate downloads method:
+Then your clinic staff has the less-than-efficient process of trying to overlay all those different devices into some sort of cohesive strategy for how your diabetes may need some tweaks. Because of Loop use, a clinic currently has to look at separate reports from Medtronic pump, Contour Next Link BG meter, Dexcom CGM/Clarity, and our iPhone Health app, as a typical example. There are also a couple of issues with Loop when using this separate download method:
 
 * Medtronic’s pump gets so clogged up by the numerous temporary basal rate records being recorded that the clinic can only pull about 7 days of data from the pump at most.
 
diff --git a/docs/how-to/bolus.md b/docs/how-to/bolus.md
index 048fb4a..a88616b 100644
--- a/docs/how-to/bolus.md
+++ b/docs/how-to/bolus.md
@@ -1,10 +1,10 @@
 # Extended or Combo Bolus with Loop
 
-The majority of meals have most of their blood glucose impact within 2-3 hours after eating.  Complex carbohydrates are slowed by their fat and protein content and can lead to extended time of blood glucose impacts. Many people with type 1 are familiar with the late blood glucose spikes from Chinese food, pasta, pizza or burritos. This extended blood glucose impact can be tricky to properly bolus for in traditional one-bolus insulin delivery.
+The majority of meals have most of their blood glucose impact within 2-3 hours after eating.  Complex carbohydrates are slowed by their fat and protein content and can lead to extended time of blood glucose impacts. Many people with type 1 are familiar with the late blood glucose spikes from Chinese food, pasta, pizza, or burritos. This extended blood glucose impact can be tricky to properly bolus for in traditional one-bolus insulin delivery.
 
 In traditional multiple daily injection therapy, these complex meals may require additional insulin boluses to help control long, slow absorption meals. The trick is to try to time the second bolus at a time when blood glucose is starting to rise and it can be tricky to estimate how much to give to control the tail end of those slow meals.
 
-If you're using traditional pump therapy, one technique is to use an extended bolus or dual wave bolus for your complex meal's insulin. In this method, a user give a portion of the insulin up front as an initial bolus and the remainder of the insulin is delivered as a psuedo high temp basal for a user-set duration of time. For example, you may give 5 units of bolus up-front and then "extend" 4 units of insulin over the next 60 minutes. In this way, you are providing a more complex bolus to help match the timing of the meal's blood glucose impacts; avoiding early low blood glucose and addressing later high blood glucose.
+If you're using traditional pump therapy, one technique is to use an extended bolus or dual wave bolus for your complex meal's insulin. In this method, a user give a portion of the insulin up front as an initial bolus and the remainder of the insulin is delivered as a pseudo high temp basal for a user-set duration of time. For example, you may give 5 units of bolus up-front and then "extend" 4 units of insulin over the next 60 minutes. In this way, you are providing a more complex bolus to help match the timing of the meal's blood glucose impacts; avoiding early low blood glucose and addressing later high blood glucose.
 
 The transition to Loop use may be confusing at first for these meals since you cannot use an extended/combo bolus and simultaneously have Loop set temporary basals automatically. The good news is that Loop has a bolus calculator that has the ability to emulate an extended bolus situation...and it's implemented with the pizza icon (or any custom carbohydrate absorption that is set longer than 4 hours).
 
@@ -17,23 +17,23 @@ For an example of Loop's bolus adjustments using carbohydrate absorption time, l
 ![Pizza Bolus](img/pizza_bolus.jpg){width="400"}
 {align="center"}
 
-The initial meal entry was 70g at a "pizza" icon aborption time (4 hours). Based on carbohydrate ratio of 8 g/U, the initial bowl of risotto at 60g should have been a bolus of 7.5 units. Loop recommended 5.3 units, or about 70% of the total bolus that would be needed to cover the total carbohydrates. Loop recommended the lower upfront bolus because a full bolus would have overwhelmed the slow absorption of carbohydrates, and the likelihood would be a low blood glucose shortly after eating. 
+The initial meal entry was 70g at a "pizza" icon absorption time (4 hours). Based on a carbohydrate ratio of 8 g/U, the initial bowl of risotto at 60g should have been a bolus of 7.5 units. Loop recommended 5.3 units or about 70% of the total bolus that would be needed to cover the total carbohydrates. Loop recommended the lower upfront bolus because a full bolus would have overwhelmed the slow absorption of carbohydrates, and the likelihood would be a low blood glucose shortly after eating. 
 
-As the meal was being absorped, Loop was tracking the carbohydrates still remaining to be absorped and expecting that blood glucose values would be rising soon (knowing that there was still insulin needing to be delivered once safely passed the near-meal low blood glucose potential). Loop would have provided the additional insulin via high temporary basals after seeing blood glucose impacts which indicated the potential for a low blood glucose had passed. 
+As the meal was being absorbed, Loop was tracking the carbohydrates still remaining to be absorbed and expecting that blood glucose values would be rising soon (knowing that there was still insulin needing to be delivered once safely passed the near-meal low blood glucose potential). Loop would have provided the additional insulin via high temporary basals after seeing blood glucose impacts which indicated the potential for a low blood glucose had passed. 
 
-The Loop user then had a second, smaller bowl of risotto about 90 minutes later, and entered 30g at 4 hours absorption again. Notice this bowl of risotto had a bolus recommendation much different than the original bowl. The second bowl had a recommendation of 5 units, much greater amount of bolus relative to the amount of carbs entered than the first bowl had received, and more than the carbohydrate ratio alone would provide (3.75 units). Why the "extra" 1.25 units? Because Loop was including *some* extra bolus amount to cover what it predicted could safely be provided from the amount *not* given in the original bowl's bolus (the original bolus was approximately 2.2 units short of carbohydrate ratio alone recommendation). If the user had not had the second bowl, Loop would have been providing high temporary basals as soon as blood glucose had exceeded the correction range. And in fact, you can see that Loop still provided the remaining insulin via high temporary basals as blood glucose rose after the second bowl, in effect making up the small remaining difference.
+The Loop user then had a second, smaller bowl of risotto about 90 minutes later, and entered 30g at 4 hours absorption again. Notice this bowl of risotto had a bolus recommendation much different than the original bowl. The second bowl had a recommendation of 5 units, much greater amount of bolus relative to the amount of carbs entered than the first bowl had received, and more than the carbohydrate ratio alone would provide (3.75 units). Why the "extra" 1.25 units? Because Loop was including *some* extra bolus amount to cover what it predicted could safely be provided from the amount *not* given in the original bowl's bolus (the original bolus was approximately 2.2 units short of the carbohydrate ratio alone recommendation). If the user had not had the second bowl, Loop would have been providing high temporary basals as soon as blood glucose had exceeded the correction range. And in fact, you can see that Loop still provided the remaining insulin via high temporary basals as blood glucose rose after the second bowl, in effect making up the small remaining difference.
 
 
 ## Low carb/High Fat or Keto diets
 
-The example meal above, while relatively high carbohydrate, also helps illustrate how Loop can be used to bolus effectively for low carb/high fat (LC/HF) or Keto diets.  Those diets tend to have low glycemic index food with a relatively long blood glucose impact.  Said another way, they don't spike blood sugar as much, but often need additional insulin after the meal was eaten to account for the slow conversion of protein to glucose.
+The example meal above, while relatively high carbohydrate, also helps illustrate how Loop can be used to bolus effectively for low carb/high fat (LC/HF) or Keto diets.  Those diets tend to have low glycemic index food with a relatively long blood glucose impact.  Said another way, they don't spike blood sugar as much but often need additional insulin after the meal was eaten to account for the slow conversion of protein to glucose.
 
 To account for those dietary differences, there are two useful strategies:
 
 * convert some of the protein and fat to "equivalent carbohydrates" and
 * extend the duration of those carbohydrates using a pizza icon or even longer, depending on the person/food.
 
-Most LC/HF or Keto users will convert a portion of their fat and protein content into an equivent carbohydrate content.  So while an example meal might only have 5g of carbohydrates based on nutritional labels, they may convert 25% of the 20g fat and 50% of the 20g protein grams into an additional 15g of "equivalent carbs" for bolusing purposes. The percentages that people use to convert fat and protein will usually be a bit of trial-and-error, but there are some published articles ([here](https://www.practicaldiabetes.com/article/fat-protein-counting-type-1-diabetes/), [here](https://www.ncbi.nlm.nih.gov/pubmed/21949219/), [here](https://youngandt1.com/how-to-bolus-for-fat-and-protein/), and [here](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3609492/)) that may be helpful starting points, if you are interested.
+Most LC/HF or Keto users will convert a portion of their fat and protein content into an equivalent carbohydrate content.  So while an example meal might only have 5g of carbohydrates based on nutritional labels, they may convert 25% of the 20g fat and 50% of the 20g protein grams into an additional 15g of "equivalent carbs" for bolusing purposes. The percentages that people use to convert fat and protein will usually be a bit of trial-and-error, but there are some published articles ([here](https://www.practicaldiabetes.com/article/fat-protein-counting-type-1-diabetes/), [here](https://www.ncbi.nlm.nih.gov/pubmed/21949219/), [here](https://youngandt1.com/how-to-bolus-for-fat-and-protein/), and [here](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3609492/)) that may be helpful starting points if you are interested.
 
 
 
diff --git a/docs/how-to/cgm.md b/docs/how-to/cgm.md
index f43ba2e..98cf078 100644
--- a/docs/how-to/cgm.md
+++ b/docs/how-to/cgm.md
@@ -26,14 +26,13 @@ We similarly see an increase in sensor noise at the end of a sensor's useful lif
 
 ![noisy old G6 sensor](img/end_of_sensor.jpeg)
 
-There is a marked increase in sensor noise and scatter, as well as several periods of sensor error that lead to lost CGM data. We opted to pull this sensor just shy of the 10 days due to this noise. However, as you can see, the Loop was still doing an aequate job controling overall blood glucose fluctuations despite the erratic CGM data.
+There is a marked increase in sensor noise and scatter, as well as several periods of sensor error that lead to lost CGM data. We opted to pull this sensor just shy of the 10 days due to this noise. However, as you can see, the Loop was still doing an adequate job controlling overall blood glucose fluctuations despite the erratic CGM data.
 
 ## Compression lows
-A frequent question from people before starting Loop is "*How does Loop deal with compression lows?*"  If you aren't familiar with compression lows, they are false low blood glucose alarms caused by sustained pressure on the sensor area. In effect, the phenomenom is much like resting on an arm for too long and causing it to fall asleep from poor blood flow.
+A frequent question from people before starting Loop is "*How does Loop deal with compression lows?*"  If you aren't familiar with compression lows, they are false low blood glucose alarms caused by sustained pressure on the sensor area. In effect, the phenomenon is much like resting on an arm for too long and causing it to fall asleep from poor blood flow.
 
-<p align="center">
-<img src="../img/compression-low.jpg" width="300">
-</p>
+![compression low](img/compression-low.jpg){width="300"}
+{align="center"}
 
 The figure above showing an example of a compression low. CGM data shows blood glucose dropping low, but finger checks on a meter would confirm that the CGM data is falsely low. Often, Dexcom G5 and G6 will stop providing CGM values for awhile when their algorithm detects a suspected compression low. Once the person rolls off the sensor area and blood starts flowing well again, the CGM values come back online to a more reasonable tracking again. 
 
diff --git a/docs/how-to/iob.md b/docs/how-to/iob.md
index a69a3c7..685f173 100644
--- a/docs/how-to/iob.md
+++ b/docs/how-to/iob.md
@@ -4,7 +4,7 @@ One of the easiest habits to help check your settings is to simply check-in on y
 
 This Looped group post started the conversation:
 
-!!! note " "
+!!! note "&nbsp;"
 
     *I've been having more lows recently than I would like. Any help here would be really really appreciated.*
     
@@ -26,7 +26,7 @@ Firstly, if the user were to bolus while carrying a lot of negative iob, they wo
 
 Secondly, if the user were to go above their correction range, they would begin to get high temporary basals for what is an inaccurate amount of negative iob (because basals really didn't need to be this high). And high temporary basals at this point in time and with these settings would be too aggressive. (If the maximum basal is set really high, the problem compounds with bad underlying settings. This is why it is a good idea to keep your maximum basal relatively low when you first start Loop and are testing your settings.)
 
-!!! info "Useful Summary"
+!!! abstract "Useful Summary"
     You probably need to lower your overnight basal rates if you wake up:
     
      * Carrying negative IOB, and
diff --git a/docs/settings/overview.md b/docs/settings/overview.md
index 85969a4..18cd2ef 100644
--- a/docs/settings/overview.md
+++ b/docs/settings/overview.md
@@ -16,7 +16,7 @@ Loop is primarily a set of math equations called an algorithm.  The recommendati
 
 Let's start by thinking about basal rates.  A well-adjusted basal schedule is designed to keep your blood glucose steady throughout the day, everything else being equal. If you were to not eat, not exercise, and basically keep a mellow lifestyle...basals should keep your blood glucose steady.  
 
-That is how Loop's math starts, and it's an important point to remember as you use and learn your Loop app.  Loop's math is based on the assumption that the basal schedule you have provided in your settings are capable of keeping your blood glucose steady in the absence of other stressors.  So as your blood glucose goes higher than your correction range for an unusual short-term influence like stress or unannounced carbs, you've been accoustomed to delivering a "correction bolus" to get back to range. Or if blood glucose goes below your correction range, you may need to eat recovery carbohydrates.
+That is how Loop's math starts, and it's an important point to remember as you use and learn your Loop app.  Loop's math is based on the assumption that the basal schedule you have provided in your settings are capable of keeping your blood glucose steady in the absence of other stressors.  So as your blood glucose goes higher than your correction range for an unusual short-term influence like stress or unannounced carbs, you've been accustomed to delivering a "correction bolus" to get back to range. Or if blood glucose goes below your correction range, you may need to eat recovery carbohydrates.
 
 With all the excitement about automated insulin delivery, some people mistakenly assume that the user's settings don't matter anymore....that **<i>everything</i>** is automated. However, settings do still matter as they provide the basis for Loop's math.  Diabetes is not a static math equation. Loop does not adjust your settings for you, that responsibility still falls to the Loop user when needed.