Ratpack - User contributions [en]

Itinerary

2026-08-02T02:10:59Z

Nelson:

[[Category:Meetings]]

Nelson: Bob's method of interpreting frequencies

ADC

2026-08-02T02:10:14Z

Nelson:

[[Category:Index]]

https://en.wikipedia.org/wiki/Goertzel_algorithm

I am wondering how well this will work for selecting a square wave. I'll try to do a demo in python.

== Gay bob's idea ==

Just use a first difference, maybe taking it a few samples back, and see when that becomes big enough, then record that as a transition, and calculate the average difference in time between them over the period.

File:2026 07 31-Meeting.png

2026-07-31T19:56:49Z

Nelson:

2026 07 31-Meeting

2026-07-31T19:56:45Z

Nelson:

[[Category:Meetings]]

Most of the meeting time was spent discussing and defining the [[DAC]] Contract, to be implemented by next week

The [[Formatting]] page now defines a rough style guide for code going forward.

DMA:
- Oneshot: writes a long bit of data to a section out/in from adc/dac
- Circular: Reruns over the same circular buffer repeatedly
- DMA Shares AHB system bus with other masters

Next week Goals: 16:00 Friday Meeting, Me and Ben in this room
- Hardware testing, Will scope the connections next meeting
- Have dac output pipeline all the way from a faux packet_framer() to the Dac outputting
- Make past code conform to style guide
- Get completed commits from BeanBranch into main

[[File:2026_07_31-Meeting.png]]

DAC

2026-07-31T19:56:06Z

Nelson: /* Timer6 Interrupts */

[[Category:Contracts]]

== DataBlock Struct ==
```
typedef struct {
int length; // Length in bits
int current_index; // current position *TO BE READ NEXT* in bits
uint8_t flags; // an area to communicate between different things accessing this memory
const int max_length; // maximum length which can be stored in `data` in bits
const uint8_t* data; // pointer to uint8 array to store data in
} DataBlock_s;
```

== FLAGS Data ==
- 0 for DAC_STOPPED
- 1 for DAC_WORKING

== Dac Outputting Overview ==
- Setup handled by DAC_init()
- Tim3 will hold a given frequency, it has an approximately 0.5second period. This is how long the high freq is held for the one bit.
- Once Tim3 finishes, it will call a handler that checks if done, or sets Tim6 ARR depending on the next bit
- Tim6 will at halfway through set the dac's output to 1, and at the end set the dac's output to 0. This has a frequency on the order of 1.2kHz, or 2.4kHz. This will transmit the frequency for the duration of Tim3's output

- From packet_framer() we write the DataBlock_s->length and ->data fields, then call DAC_init()

== DAC_init() ==
- Set current_index to zero
- set flags to 1 to mean the dac is working, external stuff should respect that and not try to write into this block
- Enable Tim6
- Enable radio PTT (once implemented)
- Enable Tim3
- Manually set Tim3 to max value to 'naturally' trigger a reset? Is this possible? We could also just call the handler, but then we get a race condition I think if the timer's going and other interrupts could delay it? We could also just wait 0.5s for it to happen actually naturally

== Timer3 Interrupt ==
The long one that changes the frequency of TIm6
- if current position is less than message length
- Get the bit stated by current_index and set TIM6's ARR accordingly to hf if it's a 1, or lf it's a 0. Remember that current_index is the bit index
- else (current pos is strictly greater than message length)
- Disable radio PTT (once implemented)
- Stop Tim6
- Stop Tim3
- Set ->flags to 0 to indicate done transmitting

== Timer6 Interrupts ==
The fast one that sends 0s and 1s to the dac

This could alternately be implemented by xoring 1 with the old value and only having an interrupt at the end of a faster timer, but reading the old value is likely less worth it.

Two interrupts method (I think better?)
Halfway interrupt: Write 1 into dac
Fullway interrupt: Write 0 into dac

ADC

2026-07-31T19:55:36Z

Nelson:

[[Category:Index]]

https://en.wikipedia.org/wiki/Goertzel_algorithm

I am wondering how well this will work for selecting a square wave. I'll try to do a demo in python.

DAC

2026-07-31T19:54:10Z

Nelson: /* Timer6 Interrupts */

[[Category:Contracts]]

== DataBlock Struct ==
```
typedef struct {
int length; // Length in bits
int current_index; // current position *TO BE READ NEXT* in bits
uint8_t flags; // an area to communicate between different things accessing this memory
const int max_length; // maximum length which can be stored in `data` in bits
const uint8_t* data; // pointer to uint8 array to store data in
} DataBlock_s;
```

== FLAGS Data ==
- 0 for DAC_STOPPED
- 1 for DAC_WORKING

== Dac Outputting Overview ==
- Setup handled by DAC_init()
- Tim3 will hold a given frequency, it has an approximately 0.5second period. This is how long the high freq is held for the one bit.
- Once Tim3 finishes, it will call a handler that checks if done, or sets Tim6 ARR depending on the next bit
- Tim6 will at halfway through set the dac's output to 1, and at the end set the dac's output to 0. This has a frequency on the order of 1.2kHz, or 2.4kHz. This will transmit the frequency for the duration of Tim3's output

- From packet_framer() we write the DataBlock_s->length and ->data fields, then call DAC_init()

== DAC_init() ==
- Set current_index to zero
- set flags to 1 to mean the dac is working, external stuff should respect that and not try to write into this block
- Enable Tim6
- Enable radio PTT (once implemented)
- Enable Tim3
- Manually set Tim3 to max value to 'naturally' trigger a reset? Is this possible? We could also just call the handler, but then we get a race condition I think if the timer's going and other interrupts could delay it? We could also just wait 0.5s for it to happen actually naturally

== Timer3 Interrupt ==
The long one that changes the frequency of TIm6
- if current position is less than message length
- Get the bit stated by current_index and set TIM6's ARR accordingly to hf if it's a 1, or lf it's a 0. Remember that current_index is the bit index
- else (current pos is strictly greater than message length)
- Disable radio PTT (once implemented)
- Stop Tim6
- Stop Tim3
- Set ->flags to 0 to indicate done transmitting

== Timer6 Interrupts ==
The fast one that sends 0s and 1s to the dac

Halfway interrupt: Write 1 into dac
Fullway interrupt: Write 0 into dac

This could alternately be implemented by xoring 1 with the old value and only having an interrupt at the end of a faster timer, but reading the old value is likely less worth it.

2026 07 31-Meeting

2026-07-31T19:46:46Z

Nelson:

Category:Contracts

2026-07-31T19:44:18Z

Nelson: Created page with "Category:Index Code contracts and definitions. This file is the source of truth, follow it, or discuss and change it."

[[Category:Index]]
Code contracts and definitions. This file is the source of truth, follow it, or discuss and change it.

DAC

2026-07-31T19:42:57Z

Nelson: Created page with "Category:Contracts == DataBlock Struct == ``` typedef struct { int length; // Length in bits int current_index; // current position *TO BE READ NEXT* in bits uint8_t flags; // an area to communicate between different things accessing this memory const int max_length; // maximum length which can be stored in `data` in bits const uint8_t* data; // pointer to uint8 array to store data in } DataBlock_s; ``` == FLAGS Data == - 0 for DAC_STOP..."

[[Category:Contracts]]

== DataBlock Struct ==
```
typedef struct {
int length; // Length in bits
int current_index; // current position *TO BE READ NEXT* in bits
uint8_t flags; // an area to communicate between different things accessing this memory
const int max_length; // maximum length which can be stored in `data` in bits
const uint8_t* data; // pointer to uint8 array to store data in
} DataBlock_s;
```

== FLAGS Data ==
- 0 for DAC_STOPPED
- 1 for DAC_WORKING

== Dac Outputting Overview ==
- Setup handled by DAC_init()
- Tim3 will hold a given frequency, it has an approximately 0.5second period. This is how long the high freq is held for the one bit.
- Once Tim3 finishes, it will call a handler that checks if done, or sets Tim6 ARR depending on the next bit
- Tim6 will at halfway through set the dac's output to 1, and at the end set the dac's output to 0. This has a frequency on the order of 1.2kHz, or 2.4kHz. This will transmit the frequency for the duration of Tim3's output

- From packet_framer() we write the DataBlock_s->length and ->data fields, then call DAC_init()

== DAC_init() ==
- Set current_index to zero
- set flags to 1 to mean the dac is working, external stuff should respect that and not try to write into this block
- Enable Tim6
- Enable radio PTT (once implemented)
- Enable Tim3
- Manually set Tim3 to max value to 'naturally' trigger a reset? Is this possible? We could also just call the handler, but then we get a race condition I think if the timer's going and other interrupts could delay it? We could also just wait 0.5s for it to happen actually naturally

== Timer3 Interrupt ==
The long one that changes the frequency of TIm6
- if current position is less than message length
- Get the bit stated by current_index and set TIM6's ARR accordingly to hf if it's a 1, or lf it's a 0. Remember that current_index is the bit index
- else (current pos is strictly greater than message length)
- Disable radio PTT (once implemented)
- Stop Tim6
- Stop Tim3
- Set ->flags to 0 to indicate done transmitting

== Timer6 Interrupts ==
The fast one that sends 0s and 1s to the dac

Halfway interrupt
- Write 1 into dac

Fullway interrupt
- Write 0 into dac

Formatting

2026-07-31T19:14:09Z

Nelson:

[[Category:Index]]

== 2026 07 31 ==
What format do we use to name things?
- Using "/**" then " * " then " */" to write comments
- Method names: Upper Snake Case
- Struct names: Upper Snake Case, append "_t"
- Variables: Lower Snake Case
- Files:
- .c, .h, .txt Lowercase with underscores
- .txt and .json Upper Camel Case
- Folders: By vibes

Commit formatting:
- https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13
- <type>(<optional scope>): <description>
- Common Types:
- feat: commits that add or adjust a feature
- fix
- refactor
- style: formatting stuff that does not affect
- test: stuff to do with unit testing
- docs
- build: stuff relating to build frameworks and tools

Formatting

2026-07-31T19:13:47Z

Nelson:

== 2026 07 31 ==
What format do we use to name things?
- Using "/**" then " * " then " */" to write comments
- Method names: Upper Snake Case
- Struct names: Upper Snake Case, append "_t"
- Variables: Lower Snake Case
- Files:
- .c, .h, .txt Lowercase with underscores
- .txt and .json Upper Camel Case
- Folders: By vibes

Commit formatting:
- https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13
- <type>(<optional scope>): <description>
- Common Types:
- feat: commits that add or adjust a feature
- fix
- refactor
- style: formatting stuff that does not affect
- test: stuff to do with unit testing
- docs
- build: stuff relating to build frameworks and tools

2026 07 31-Meeting

2026-07-31T18:59:19Z

Nelson:

[[Category:Meetings]]

DMA:
- Oneshot: writes a long bit of data to a section out/in from adc/dac
- Circular: Reruns over the same circular buffer repeatedly
- DMA Shares AHB system bus with other masters

I'm writing [[DAC]] to define the contracts we plan to implement by next week.

Next week Goals: 16:00 Friday Meeting, Me and Ben in this room
- Hardware testing, Will scope the connections next meeting
- Have dac output pipeline all the way from a faux packet_framer() to the Dac outputting

Formatting

2026-07-31T18:41:36Z

Nelson: Created page with "== 2026 07 31 == What format do we use to name things? - Using "/**" then " * " then " */" to write comments - Method names: Upper Snake Case - Struct names: Upper Snake Case, append "_t" - Variables: Lower Snake Case - Files: - .c, .h, .txt Lowercase with underscores - .txt and .json Upper Camel Case - Folders: By vibes"

Itinerary

2026-07-31T18:41:14Z

Nelson: Replaced content with "Category:Meetings"

[[Category:Meetings]]

2026 07 31-Meeting

2026-07-31T17:47:41Z

Nelson:

2026 07 31-Meeting

2026-07-31T17:41:38Z

Nelson:

[[Category:Meetings]]

DMA:
- Oneshot: writes a long bit of data to a section out/in from adc/dac
- Circular: Reruns over the same circular buffer repeatedly

2026 07 31-Meeting

2026-07-31T17:39:48Z

Nelson: Created page with "Category:Meetings Beans!"

[[Category:Meetings]]

Beans!

Itinerary

2026-07-31T05:58:30Z

Nelson: Created page with "Category:Meetings What format do we use to name things"

[[Category:Meetings]]

What format do we use to name things

ADC

2026-07-31T05:04:10Z

Nelson: Created page with "Category:Index https://en.wikipedia.org/wiki/Goertzel_algorithm"

[[Category:Index]]

https://en.wikipedia.org/wiki/Goertzel_algorithm

2026 07 23-Meeting

2026-07-31T04:36:08Z

Nelson:

[[Category:Meetings]]

Discussed how the radio side should be structured
- Protocol block will call `int frame_packet(unframed_packet* data_source, framed_packet* data_dest) {` after writing message data into data_source
- Frame packet will split by MTU, frame each, and schedule the dac interupt
- ADC's raw data buffer needs to be decoded often, we're really memory limited here

- We're going to allocate everything once at the start of main, then propigate the pointers down. This way we only need to allocate big things once, and the rest can just chill

Discussed wanting to do smaller things weekly
- Planning to try and finish the skeleton of the dac pathway below, by our meeting next friday at 11:30

[[File:2026_07_23-Meeting.png]]

2026 06 24-Meeting

2026-07-31T04:35:31Z

Nelson:

[[Category:Meetings]]

Most of what was decided on was turned into *The* [[Protocol]] spec.

[[File:2026_06_24-Meeting.png]]

File:2026 07 23-Meeting.png

2026-07-31T04:32:43Z

Nelson:

File:2026 06 24-Meeting.png

2026-07-31T04:27:29Z

Nelson:

2026 06 24-Meeting

2026-07-31T04:18:19Z

Nelson: Created page with "Category:Meetings Most of what was decided on was turned into *The* Protocol spec."

[[Category:Meetings]]

Most of what was decided on was turned into *The* [[Protocol]] spec.

2026 07 23-Meeting

2026-07-23T22:43:30Z

Nelson:

Category:Meetings

2026-07-23T22:11:20Z

Nelson:

[[Category:Index]]
Meeting Logs

Category:Meetings

2026-07-23T22:10:24Z

Nelson: Created page with "Meeting Logs"

Meeting Logs

Meetings

2026-07-23T22:09:13Z

Nelson: Created page with "See https://ratpack.ece.utah.edu/index.php/Category:Meetings"

See https://ratpack.ece.utah.edu/index.php/Category:Meetings

2026 07 23-Meeting

2026-07-23T22:08:53Z

Nelson: Created page with "Category:Meetings Beans!"

[[Category:Meetings]]

Beans!

Protocol

2026-06-25T03:25:16Z

Nelson: /* Packet Framing */

[[Category:Index]]

== Overview ==
When data should be sent, a packet is generated, this is an arbitrary bit string of arbitrary length. If the packet gets above a threshold, call it an MTU for Max Transfer Unit, then the packet can be split into multiple frames. Each frame is one transmission, containing part or all of a packet, and meta information about itself.

The idea is that by splitting and framing packets, we are able to reduce the amount of continuous air time in use, and reduce issues caused by drift in the bit detection

Some transmissions are framed, others are not to save space. See the [[Protocol#Transaction Format|Transaction Format]] below

== Transaction Format ==
A ____ | Unframed, Occasionally broadcast ping to say ready to transmit, maybe once every two minutes or something
A <- B | Unframed, Reply to A's broadcast, just different(?) preamble then A's callsign, then B's callsign
A -> B | Framed packet, containing list of message hashes
A <- B | Framed packet, containing list of message hashes
A -> B | Framed packet, List of hashes A does hot have
A <- B | Framed packet, List of hashes B does hot have
A -> B | Framed packet, Message data for all requested packets B is missing
A <- B | Framed packet, Message data for all requested packets A is missing

== Packet Framing ==
- One frame contains a preamble, header, packet/packet part, footer

=== Preamble ===
- More than a standard bit string, could just stop transmitting within the block. This will allow the reciever to calibrate their bit width offset
- All messages start this way in some fashion
- Used to detect if this is a transmission for us, or another mode like someone just talking we can ignore
- It could be worth having a distinct preamble for framed packets vs freeform want-to-talk/reply-to-want-to-talk packets
- Something like 11110000110011001010 could be cool, the goal is that it can be listening periodically, then have enough time to spool up the math, and set the timing for where bit edges are

=== Header ===
- Contains meta information about the packet/packet part
- Size of data block in bits/bytes (TBD)
- Hash/Checksum/Parity to verify message integrity (TBD, I vote start with single parity bit, then get more complicated once we're good at this)
- Callsign of sender, need to decide on format. It may be worth finding a standard already in place for amateur radio
- Callsign of intended recipient (Do we want this?)
- Section to say if we are a part of a split packet, and if so, what number out of how many we are, maybe just reserve two bytes for me/total

=== Packet ===
- Arbitrary data, split to fit in frame's MTU then reconstructed

=== Footer ===
- Like header but less
- parity/checksum again(?)
- Callsign of sender in standard format again -- I think this should be the end of the message so if someone doesn't know the format they can do it
- Maybe beep it out in morse code using more standard fm ptt also

Protocol

2026-06-25T03:24:51Z

Nelson:

Protocol

2026-06-25T03:23:33Z

Nelson: /* Overview */

[[Category:Index]]

== Overview ==
When data should be sent, a packet is generated, this is an arbitrary bit string of arbitrary length. If the packet gets above a threshold, call it an MTU for Max Transfer Unit, then the packet can be split into multiple frames. Each frame is one transmission, containing part or all of a packet, and meta information about itself.

The idea is that by splitting and framing packets, we are able to reduce the amount of continuous air time in use, and reduce issues caused by drift in the bit detection

Some transmissions are framed, others are not to save space. See the [[Protocol#Transaction Format|Transaction Format]] below

== Transaction Format ==
A ____ | Unframed, Occasionally broadcast ping to say ready to transmit, maybe once every two minutes or something
A <- B | Unframed, Reply to A's broadcast, just different(?) preamble then A's callsign, then B's callsign
A -> B | Framed packet, containing list of message hashes
A <- B | Framed packet, containing list of message hashes
A -> B | Framed packet, List of hashes A does hot have
A <- B | Framed packet, List of hashes B does hot have
A -> B | Framed packet, Message data for all requested packets B is missing
A <- B | Framed packet, Message data for all requested packets A is missing

== Packet Framing ==
- One frame contains a preamble, header, packet/packet part, footer

=== Preamble ===
- Just a standardized bit string
- All messages start this way
- Lets the receiver set timing offset for bit transitions
- Used to detect if this is a transmission for us, or another mode like someone just talking we can ignore
- It could be worth having a distinct preamble for framed packets vs freeform want-to-talk/reply-to-want-to-talk packets
- Something like 11110000110011001010 could be cool, the goal is that it can be listening periodically, then have enough time to spool up the math, and set the timing for where bit edges are

=== Header ===
- Contains meta information about the packet/packet part
- Size of data block in bits/bytes (TBD)
- Hash/Checksum/Parity to verify message integrity (TBD, I vote start with single parity bit, then get more complicated once we're good at this)
- Callsign of sender, need to decide on format. It may be worth finding a standard already in place for amateur radio
- Callsign of intended recipient (Do we want this?)
- Section to say if we are a part of a split packet, and if so, what number out of how many we are, maybe just reserve two bytes for me/total

=== Packet ===
- Arbitrary data, split to fit in frame's MTU then reconstructed

=== Footer ===
- Like header but less
- parity/checksum again(?)
- Callsign of sender in standard format again -- I think this should be the end of the message so if someone doesn't know the format they can do it
- Maybe beep it out in morse code using more standard fm ptt also

Protocol

2026-06-25T03:11:34Z

Nelson: Create protocol page to reflect protocol as decided in 2026_06_24 Meeting (and mostly my whims)

[[Category:Index]]

== Overview ==
When data should be sent, a packet is generated, this is an arbitrary bit string of arbitrary length. If the packet gets above a threshold, call it an MTU for Max Transfer Unit, then the packet can be split into multiple frames. Each frame is one transmission, containing part or all of a packet, and meta information about itself.

The idea is that by splitting and framing packets, we are able to reduce the amount of continuous air time in use, and reduce issues caused by drift in the bit detection

Some transmissions are framed, others are not to save space. See the Transaction section below

TODO: How do you reference sections? would be cool if "Transaction Section" in above line was a link (am writing in vim on the bus with no internet)

=== Transaction ===
A ____ | Unframed, Occasionally broadcast ping to say ready to transmit, maybe once every two minutes or something
A <- B | Unframed, Reply to A's broadcast, just different(?) preamble then A's callsign, then B's callsign
A -> B | Framed packet, containing list of message hashes
A <- B | Framed packet, containing list of message hashes
A -> B | Framed packet, List of hashes A does hot have
A <- B | Framed packet, List of hashes B does hot have
A -> B | Framed packet, Message data for all requested packets B is missing
A <- B | Framed packet, Message data for all requested packets A is missing

=== Packet Framing ===
- One frame contains a preamble, header, packet/packet part, footer

==== Preamble ====
- Just a standardized bit string
- All messages start this way
- Lets the receiver set timing offset for bit transitions
- Used to detect if this is a transmission for us, or another mode like someone just talking we can ignore
- It could be worth having a distinct preamble for framed packets vs freeform want-to-talk/reply-to-want-to-talk packets
- Something like 11110000110011001010 could be cool, the goal is that it can be listening periodically, then have enough time to spool up the math, and set the timing for where bit edges are

==== Header ====
- Contains meta information about the packet/packet part
- Size of data block in bits/bytes (TBD)
- Hash/Checksum/Parity to verify message integrity (TBD, I vote start with single parity bit, then get more complicated once we're good at this)
- Callsign of sender, need to decide on format. It may be worth finding a standard already in place for amateur radio
- Callsign of intended recipient (Do we want this?)
- Section to say if we are a part of a split packet, and if so, what number out of how many we are, maybe just reserve two bytes for me/total

==== Packet ====
- Arbitrary data, See transaction above

==== Footer ====
- Like header but less
- parity/checksum again(?)
- Callsign of sender in standard format again -- I think this should be the end of the message so if someone doesn't know the format they can do it
- Maybe beep it out in morse code using more standard fm ptt also

Expenses

2026-06-09T21:33:01Z

Nelson: Created page with "== List of Expenses == == Nelson's problem: not to be split == - $5.23 -- remainder for stm32"

== List of Expenses ==

== Nelson's problem: not to be split ==
- $5.23 -- remainder for stm32

Shared Documents

2026-04-14T22:24:25Z

Nelson:

[[Category:Index]]

Final Presentation: https://docs.google.com/presentation/d/1z0RWML4LscDDLyI2OR0ecD0lyGYomgWG8lHGuEDNWdA/edit?usp=sharing

Final Proposal: https://docs.google.com/document/d/14ydoZ-L2-1_XbjGCP8m4bqDTo7D6e-AzSidDjeT5dfk/edit?usp=sharing
Will be typeset later, this is just for shared when writing words

Shared Documents

2026-04-14T21:37:48Z

Nelson:

Final Presentation: https://docs.google.com/presentation/d/1z0RWML4LscDDLyI2OR0ecD0lyGYomgWG8lHGuEDNWdA/edit?usp=sharing

Final Proposal: https://docs.google.com/document/d/14ydoZ-L2-1_XbjGCP8m4bqDTo7D6e-AzSidDjeT5dfk/edit?usp=sharing
Will be typeset later, this is just for shared when writing words

Shared Documents

2026-04-14T21:34:17Z

Nelson:

Shared Documents

2026-04-14T21:33:39Z

Nelson: Created page with " Final Proposal: - https://docs.google.com/document/d/14ydoZ-L2-1_XbjGCP8m4bqDTo7D6e-AzSidDjeT5dfk/edit?usp=sharing"

Final Proposal:
- https://docs.google.com/document/d/14ydoZ-L2-1_XbjGCP8m4bqDTo7D6e-AzSidDjeT5dfk/edit?usp=sharing

Category:Index

2026-04-14T21:26:31Z

Nelson: /* TO DO: Make Nelson give us sysop permissions */

2026 ECE RatPack Radio Senior Project WIki

Presentations

2026-04-08T00:35:28Z

Nelson: Created page with "= Presentations we've done = == Final Presentation == - https://docs.google.com/presentation/d/1z0RWML4LscDDLyI2OR0ecD0lyGYomgWG8lHGuEDNWdA/edit?usp=sharing"

= Presentations we've done =

== Final Presentation ==
- https://docs.google.com/presentation/d/1z0RWML4LscDDLyI2OR0ecD0lyGYomgWG8lHGuEDNWdA/edit?usp=sharing

Main Page

2026-03-06T19:25:50Z

Nelson: Redirected page to Category:Index

#REDIRECT [[:Category:Index]]

<strong>MediaWiki has been installed.</strong>

Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.

== Getting started ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

Category:Index

2026-03-06T19:22:43Z

Nelson:

2026 ECE RatPack Radio Senior Project WIki

Category:Index

2026-03-06T19:22:09Z

Nelson: Created blank page

Overview

2026-03-06T19:16:47Z

Nelson: Created page with "Category:Index Yo we have a pretty cool project"

[[Category:Index]]

Yo we have a pretty cool project